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FOREWORD 


This  document  was  prepared  in  close  coordination  with  the 
Fleet  Computer  Programming  Center,  Pacific,  as  part  of  a complete 
set  of  documentation  for  the  procurement  and  management  of  computer 
programs.  As  such  it  can  be  considered  an  integrated  part  of  a 
total  system  approach  to  computer  program  development  and  procure- 
ment. In  the  development  of  this  approach,  it  was  necessary  to 
prepare  each  package  incrementally.  Then  the  increments  were 
integrated  into  the  whole  through  an  iterative  process. 

At  the  time  of  publication,  several  iterations  have  been 
completed,  with  coordinated  inputs  from  all  known  sources.  How- 
ever, the  process  of  updating  and  refining  this  document  should 
be  a continuous  one  so  that  it  will  be  a viable  document  incor- 
porating all  advances  and  evolutionary  changes  in  computer 
programming. 

The  TDS  Computer  Program  Management  Manual  is  intended  to 
provide  guidance  to  personnel  having  responsibilities  for  the 
development,  acquisition,  and  modification  of  Tactical  Data 
System  Computer  Programs.  ■'The  core  of  this  manual  is  the  TDS 
Computer  Program  Management  Plan,  Figure  1. 

Using  Figure  1 as  a "road  map  , this  manual  provides  infor- 
mation to  acquaint  management  personnel  with  requirements  and 
procedures  for  control  of  the  development,  acquisition,  and  modif- 
ication of  TDS  computer  programs  as  well  as  the  availability  and 
use  of  other  manuals  designed  to  provide  in-depth  guidance  for 
specific  areas  of  effort  under  the  program  management  plan. 

The  manual  is  organized  in  four  sections  The  first.  Program 
Management  Planning,  includes  a discussion  of  the  document  resources 
needed  for  program  management  planning,  as  well  as  the  specific 
management  actions  to  be  taken  which  culminate  in  the  award  of  a 
contract  to  acquire  a TDS  computer  program. 
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Section  2 of  the  manual  includes  the  areas  of  design, 
development,  and  production  of  TDS  computer  programs.  It  includes 
milestone  planning  and  design  review,  configuration  and  quality- 
control,  contract  monitoring  and  the  design  and  field  testing 
leading  to  a deliverable  TDS  computer  program. 

Section  3 of  the  manual  treats  the  special  problems  of  changes 
or  modifications  to  TDS  computer  programs,  and  includes  information 
on  the  initiation,  review,  approval  and  authorization  of  changes. 

Section  4 of  the  manual  summarizes,  in  brief  form,  the  contents 
of  Sections  1 through  3 and  relates  them  to  some  of  the  considera- 
tions external  to  the  program  management  plan  which  impinge  on  the 
management  of  TDS  computer  programs . 

The  following  documents,  of  which  this  is  one,  comprise  the 
system  documentation  package: 


Title 

Publication  No. 

A Preparation  Guide  for  Request  for 
Quotation  for  Tactical  Data  System 
Computer  Programs 

414-04-1-689 

A Procurement  Specification  for 

Tactical  Data  System  Computer 

Programs 

414-04-2-690 

A Guide  for  Preparation  of  Tactical 

Data  System  Operational  Specifications 

414-04-3-691 

Tactical  Data  System  Computer 

Programming  Specification 

414-04-4-692 

A Specification  for  Tactical  Data 

System  Computer  Program  Documentation 

414-04-5-693 

A Management  Manual  for  Tactical  Data 
System  Computer  Programs 

414-04-6-694 

1.  PROGRAM  MANAGEMENT  PLAi'fNING 


1 . 1  Applicable  Documents 

This  section  provides  guidance  to  the  documents  to  be 
controlled  within  the  TDS  computer  program  complex.  Certain  of 
these  documents  which  are  critical  to  the  success  of  the  management 
plan  will  be  discussed  in  greater  detail  in  subsequent  sections  of 
the  manual.  In  addition  to  internal  documents,  this  section  will 
discuss  pertinent  documents  external  to  the  TDS  computer  program 
which  provide  significant  requirements  to  be  met  by  the  management 
plan,  ^eciion  will  discuss  the  necessity  for  rigorous  control 
of  documentation  in  the  management  of  a TDS  computer  program,  and 
the  organization  of  the  Documentation  Library  needed  to  implement 
this  control^  ^ or— 

1.1.1  The  Technical  Development  Plan  fTDP) 

The  principal  document  of  concern  external  to  the  TDS  computer 
program  complex  is  the  Technical  Development  Plan.  This  document 
is  the  responsibility  of  the  cognizant  System  Command  and,  when 
approved  by  the  Office  of  the  Chief  of  Naval  Operations  (OPNAV), 
constitutes  the  development  authorization.  The  TDP  may  be  in  one 
of  two  forms.  It  may  address  the  TDS  as  a discrete  entity  or  it 
may  address  a weapons  system  of  which  the  TDS  is  a part.  In  either 
case,  the  TDP  provides  the  technical  guidance  for  both  the  Equip- 
ment Specifications  and  the  Operational  Specifications.  Much  of  the 
input  for  the  latter  is  obtained  from  the  Specific  Operational 
Requirement  (SOR)  which  is  an  appendix  to  the  TDP. 

In  addition  to  the  technical  and  operational  guidance  provided, 
the  TDS  Computer  Program  Manager  obtains  schedule  guidance  and 
fiscal  guidance  in  summary  form  from  Section  2 of  the  TDP  and  in 
detailed  form  in  Section  5 for  schedule  and  Section  6 for  fiscal. 

1.1.2  The  Equipment  Specification  and 
Related  Documents 

Second  in  importance  only  to  the  TDP  as  a specific  guidance 
document  is  the  Equipment  Specification.  The  Equipment  Specifica- 
tion is  the  contract  document  which  prescribes  the  characteristics 
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of  the  computer  and  peripheral  equipment  with  which  the  program  is 
to  be  used.  Frequently  the  specification  is,  in  fact,  several  spe- 
cifications, in  that  peripheral  equipments  are  often  not  completely 
accounted  for  in  the  computer  Equipment  Specification.  This 
requires  that  the  TDS  computer  program  manager  check  Sections  4,  8, 
and  9 of  the  TDP  to  Insure  that  all  necessary  equipment  inputs  are 
at  hand  to  permit  a complete  Equipment  Description  as  a basis  for 
the  computer  program  design. 

Technical  and  operating  manuals  frequently  provide  detailed 
information  of  major  concern  to  computer  program  design  which  is 
not  cited  explicitly  in  the  equipment  specifications.  Much  rework 
and  possible  schedule  delays  can  be  avoided  by  meticulous  attention 
to  a thorough  and  comprehensive  set  of  equipment  input  data  prior 
to  any  subsequent  computer  program  design  efforts.  Section  1.3 
discusses  the  Equipment  Specification  in  greater  depth. 


1.1.3  Equipment  Description 

The  Equipment  Description  is  one  of  the  two  basic  but  specific 
guidance  documents  prepared  within  the  framework  of  responsibility 
of  the  TDS  Computer  Program  Manager.  The  other  is  the  Operational 
Specification,  which  will  be  discussed  in  Section  1.1.4. 

The  Equipment  Description  is  prepared  from  the  Equipment 
Specifications  and  manuals,  to  provide  a thorough  portrayal  of  the 
computer  and  peripheral  equipment.  It  should  be  in  terms  of 
functions  and  capabilities,  written  to  serve  as  guidance 
to  computer  program  designers.  The  Equipment  Description  serves 
two  f-unctlons.  First,  it  brings  together  in  one  document  the  total 
computer  complex — including  memories,  input-output  devices, 
buffers,  readouts,  and  all  other  peripheral  input  or  output  systems 
or  subsystems  which  are  matters  of  concern  to  successful  computer 
program  design.  The  second  function  is,  in  effect,  a translation 
from  electronic  engineering  terminology  to  that  readily  vinderstood 
by  computer  program  designers,  and  is  generally  characterized  by  a 
transformation  to  operational  fxmctlon  verbiage.  Section  1.3  dis- 
cusses the  Equipment  Description  in  greater  depth. 
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1.1.4  Operational  Specil'icatlon 

The  Operational  Specification  is  the  pivotal  document  prepared 
within  the  framework  of  responsibility  of  the  TDS  Computer  Profram 
Manager.  It  is  used  in  conjunction  with  the  Equipment  Description 
and  the  more  general  guidance  documents;  "Specification  for  TDS 
Computer  Program  System  Documentation",  and  the  "TDS  Computer  Pro- 
gramming Specification".  Both  are  discussed  in  Section  1.1.5  as 
the  principal  inputs  to  the  computer  program  Procurement  Specifica- 
tion. To  a great  extent  the  Operational  Specification  provides  the 
performance  baseline  for  the  computer  program  to  be  produced. 

Its  import  to  successful  management  of  TDS  computer  program 
procurement  is  reflected  by  the  establishment  of  a document  titled 
"TDS  Computer  Program  Operational  Specification  Preparation  Guide". 
This  guide  is  discussed  in  Section  1.4. 

1.1.5  Specification  for  TDS  Computer  Program 
System  Documentation  and  TDS  Computer 
Programming  Specification 

Both  of  these  specifications  are  standard  specifications  which 
apply  to  all  TDS  computer  programs.  The  "Specification  for  TDS 
Computer  Program  System  Documentation"  provides  guidance  to  the 
contractor  as  to  both  the  documentation  required  under  the  contract 
and  the  specific  content  and  format  for  each  of  the  field  documents 
produced.  Essentially,  this  specification  provides  the  guidance 
needed  by  the  contractor  to  carry  out  his  part  of  the  Documentation 
Library  discussed  in  Section  1.2  of  this  manual.  As  such,  the 
"Specification  for  TDS  Computer  Program  System  Documentation" 
together  with  the  "TDS  Computer  Programming  Specification",  provide 
the  configuration  control  baseline  for  management  of  the  system 
data  package. 

The  "TDS  Computer  Programming  Specification"  defines  the 
progranming  criteria,  procedures  and  methodology.  The  principal 
function  of  the  "TDS  Computer  Programming  Specification"  is  to 
ensure  that  the  structure  and  logic  of  the  program  are  documented 
in  such  a manner  that  the  program  can  be  employed  and  xmderstood  by 
the  users.  It  prescribes  the  requirements  and  format  for  program 
flow  diagrams,  fiinctlonal  descriptions  of  logic  flow  and  functional 
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flow  charts  for  the  system.  While  this  specification  does 
circumscribe  the  programming  effort,  it  serves  to  ensure  compati- 
bility of  the  developed  program  with  such  considerations  as  achiev- 
able operating  forces,  skill-levels,  and  TDS--TDS  communication, 
rather  than  to  stifle  Innovation. 

1.1.6  Procurement  Specification 

The  Procurement  Specification  serves  to  bring  together  the 
requirements  of  the  Operational  Specification,  the  "TDS  Computer 
Programming  Specification",  the  "Specification  for  TDS  Computer 
Program  System  Documentation",  the  Equipment  Description  and  the 
schedule  and  business  requirements  to  be  satisfied  by  the  con- 
tractor. While  the  input  specifications  and  the  work  statement  are 
the  technical  heart  of  the  Procurement  Specification,  the  total 
obiective  of  the  effort  can  be  prejudiced  if  careful  attention  is 
not  given  to  the  business,  schedule  and  legal  aspects. 

The  Procurement  Specification  is  discussed  In  greater  depth 
in  Section  1.5.  Guidance  in  the  preparation  of  the  Procurement 
Specification  can  be  obtained  from  the  "TDS  Standard  Computer 
Program  Procurement  Specification." 

1.1.7  Request  f o r Qyot e 

The  document  designated  as  Request  for  Quote  in  Figure  1 is 
identified  generlcally.  Actually  this  document  can  take  any  of  a 
number  of  forms,  dependent  upon  the  method  of  contracting  selected. 
If  a formally  advertised  bid  procedure  is  followed.  Standard 
Form  30  (long  form^  or  Standard  Form  33  ^'short  form)  "invitation 
for  Bid"  is  used.  In  the  case  of  a negotiated  or  competitive 
negotiation  procedure  with  definitive  specifications,  form  DD--1261 
"Request  for  Quotation"  is  used.  Di  those  cases  where  definitive 
specifications  are  not  available  form  DD-7^  "Request  for  Proposal" 
is  used.  Regardless  of  the  form  used,  close  liaison  between  the 
Computer  Program  Manager  and  the  Contracting  Officer  is  imperative. 
A more  detailed  discussion  of  this  document  is  contained  in  Sec- 
tion 1.6.  Guidance  in  this  area  can  be  found  in  the  "TDS  Computer 
Program  RPQ  Preparation  Guide". 
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1.1.8  System  Reference  Documents 

System  reference  documents  are  those  documents  which  are 
retained  in  the  Fleet  Computer  Programming  Center  reference  f j les 
and  are  subject  to  close  control  as  discussed  in  Section  1.2.  They 
include  the  Operational  Specification  and  Equipment  Description 
discussed  in  1.1.4  and  1.1.3,  respectively,  together  with  the 
following  documents  which  are  generated  by  the  contractor  in  his 
program  design  and  program  preparation  efforts. 

1 . 1 . 8 . 1 Functional  Description  of 
Logic  Flow 

The  functional  description  of  logic  flow,  together  with  its 
supporting  program  flow  diagram,  provides  a thorough  description 
of  the  logic  of  the  program.  It  is  the  essence  of  the  design  of 
the  computer  program  and  provides  a narrative  as  well  as  diagram- 
matic (program  flow  diagram)  portrayal  of  this  total  program 
design.  Upon  the  successful  completion  of  a design  review,  the 
functional  description  of  logic  flow  becomes  the  basis  of  the  com- 
puter program’s  functional  flow  chart.  Both  are  controlled  by  the 
"TDS  Computer  Programming  Specification. " 

1.1. 8. 2 Functional  Flow  Chart 

The  functional  flow  chart  is  a diagrammatic  chart  using 
standard  programming  symbology  to  describe  all  of  the  functions  in 
the  computer  program.  As  indicated  in  1. 1.8.1,  the  functional  flow 
chart  is  controlled  by  the  "TDS  Computer  Programming  Specification." 

1.1. 8. 3 Program  Card  Deck 

The  program  card  deck  is  the  collection  of  EAM  cards  on  which 
the  source  language  coding  and  comments  have  been  keypunched.  The 
program  card  deck  is  the  basic  documentation  of  the  program  speci- 
fics, and  is  controlled  by  the  "TDS  Computer  Programming 
Specification. " 

1.1. 8. 4 Source  Program  Listing 

The  source  program  history  is  a computer  generated,  in  pro- 
grammer's (English)  language,  listing  of  all  the  elements  of  the 
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source  program  showing  the  structuring  of  all  program  routines  emd 
subroutines.  This  Is  controlled  by  the  "TDS  Computer  Programming 
Specification. " 

1.1. 8. 5 Ob.lect  Program  Listing 

The  object  program  listing  Is  a computer  generated  listing  of 
the  translation  of  the  source  program  to  the  object  program  In 
machine  (binary)  language  showing  all  the  elements  and  stationing 
of  the  object  program.  It  Is  controlled  by  the  "TDS  Computer  Pro- 
gramming Specification." 

1.1. 8. 6 Test  Routine 

The  Test  Routine  causes  the  flow  of  the  program  during 
execution  to  enter  every  possible  combination  of  paths  and  to 
operate  within  the  limits  set  by  the  operational  specification.  It 
also  Includes  a routlne(s)  which  tests  the  adequacy  of  "inhibit 
Illegal  action"  provisions  of  the  program.  It  Is  controlled  by 
the  "TDS  Computer  Programming  Specification." 

1. 1.8.7  Simulation  Program 

The  simulation  program  Is  a set  of  routines  with  Input  data 
as  statistically  close  to  Input  of  real  performance  as  possible. 

It  Is  used  to  evaluate  the  effectiveness  of  the  developed  computer 
program,  and  Is  controlled  by  the  "TDS  Computer  Programming 
Specification. " 


1.1. 8. 8  Docxmient  Control  List 
The  Document  Control  List  (DCL)  Is  a running  compilation  of 
the  status  of  all  computer  program  documentation.  In  It  Is  entered 
the  specific  Identifying  nomenclature  of  each  document  together 
with  Its  current  status  and  distribution.  It  shall  also  record 
the  establishment  date  and  authority  as  well  as  all  change  dates 
and  authorities  and  their  distributions.  The  document  control  list 
serves  as  the  Index  to  the  computer  program  Documentation  Library, 
as  well  as  the  key  document  for  the  data  management  function  In 
the  development  and  production  of  computer  programs  (see  Sec- 
tions 1.2.4,  1.2.5,  and  1.2.6). 
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1.1.9  Field  Documents 

In  addition  to  the  program  tape,  seven  field  documents  are 
supplied  to  the  operating  forces.  Master  copies  of  each  of  the 
field  documents  are  retained  in  the  Fleet  Computer  Program  Ref- 
erence Library. 

1.1. 9.1  Command  and  Staff  Manual 

A broad  description  of  the  system  capability  and  limitations, 
the  Command  and  Staff  Manual  is  designed  for  flag  and  senior  staff 
officer  use.  It  is  controlled  by  Appendix  A of  the  "Specification 
for  TDS  Computer  Program  System  Documentation. " 

1.1. 9.2  System  Plan  Manual 

The  System  Plan  Manual  is  a thorough  but  non-technlcal 
description  of  system  functions  and  capabilities.  It  is  a broad 
coverage  documeiit  designed  for  use  by  fleet  operational  planning 
personnel  and  for  those  responsible  for  tactical  employment  of  the 
system.  It  is  controlled  by  Appendix  B of  the  "Specification  for 
TDS  Computer  Program  System  Documentation." 

1.1. 9. 3 System  Operation  Manual 

The  System  Operation  Manual  provides  detailed  information  and 
instructions  for  personnel  having  adequate  technical  training  to 
effect  equinment  and  program  operation.  It  is  controlled  by 
Appendix  0 of  the  "Specification  for  TDS  Computer  Program  System 
Dociunentation.  " 

1.1.9. 4 System  Program  Design  Manual 

The  System  Program  Design  Manual  contains  program  flow 
diagrams,  functional  flow  charts  and  functional  descriptions  which 
doc\iment  the  computer  program  design.  It  is  for  use  by  systems 
analysts,  logic  designers,  and  computer  programmers.  It  is  con- 
trolled by  Appendix  D of  the  "Specification  for  TDS  Computer  Pro- 
gram System  Documentation." 
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1.1. 9*5  System  Program  Assembly- 
Listing  Manual 

The  System  Program  Assembly  Listing  Manual  is  for  use  by  the 
logic  designers,  computer  programmers,  and  maintenance  technicieins. 

It  contains  the  memory  map,  annotated  source  program  listing  and 
the  object  program  listing  for  the  operational  program  routines. 

It  is  controlled  by  Appendix  E of  the  "Specification  for  TDS  Com-  t 

puter  Program  System  Documentation." 

1.1. 9.6  System  Program  Maintenance 
Manual 

The  System  Program  Maintenance  Manual  contains  the  program 
flow  diagrams,  functional  flow  charts,  fimctional  descriptions  and 
assembly  listings  for  the  maintenance  programs  and  test  routines. 

It  is  for  use  by  the  logic  designers,  computer  programmers  and 
maintenance  technicians.  It  is  controlled  by  Appendix  P of  the 
"Specification  for  TDS  Computer  Program  System  Documentation." 

1.1. 9.7  System  Programmer 
Reference  Manual 

The  System  Programmer  Reference  Manual  contains  the  program 
coding  Instructions,  word  formats,  coding  sheets,  program  assembly 
instructions,  and  program  service  instructions  for  use  by  the  com- 
puter programmers.  It  is  controlled  by  Appendix  G of  the  "Speci- 
fication for  TDS  Computer  Program  System  Documentation." 

1.1.10  Change  Recommendations 

The  three  sources  of  computer  program  change  recommendations 
from  within  the  computer  program  management  sphere  are  the  con- 
tractor, the  operating  forces  and  the  Fleet  Computer  Programming 
Centers.  Change  recommendations  may  also  be  initiated  by  the 
Systems  Commands,  the  Chief  of  Naval  Operations  or  the  Joint  Chiefs 
of  Staff.  Since  these  latter  result  in  changes  to  the  Technical 
Development  Plan,  directed  changes  to  the  Operational  Specification 
or  in  changes  to  be  implemented  by  the  Fleet  Computer  Programming  i 

Center,  their  addressal  in  this  manual  will  be  included  under 
FCPC  change  recommendations.  [ 
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1.1.10.1  Contractor  Change 
Recommendation 

Contractor  recommendations  for  computer  program  changes  to 
correct  deficiencies  exhibited  during  program  operation  in  Fleet 
use  are  discussed  in  detail  in  Section  3*1>  and  are  controlled  by 
the  procedures  set  forth  in  Section  2.2. 

1.1.10.2  FCPC  Change  Recommendations 

Recommendations  for  computer  program  changes  which  the  Fleet 

Computer  Programming  Center  prepares  either  on  its  own  Initiative 
or  as  a result  of  recommendations  or  directives  from  higher 
authority  are  discussed  in  detail  in  Section  3*1^  and  are  con- 
trolled by  the  procedures  set  forth  in  Section  2.2 

1.1.10.3  Fleet  Change  Recommendations 

Recommendations  for  computer  program  changes  which  the 

operating  forces  prepare  (either  to  correct  deficiencies  in  pro- 
gram operation  experienced  in  use  or  to  extend  the  effectiveness 
or  utility  of  the  computer  program)  are  discussed  in  detail  in 
Section  3.1»  and  are  controlled  by  the  procedures  set  forth  in 
Section  2.2. 

1.1.11  Computer  Program  Change  Proposal 

The  computer  program  change  proposal  completely  describes  the 
change (s)  accepted  by  the  Fleet  Computer  Programming  Center  for 
submission  to  computer  program  chajige  analysis  and  subsequent 
action  to  Introduce  into  the  computer  program.  This  is  discussed 
in  depth  in  Section  3.2.  Computer  program  change  analysis  is  dis- 
cussed in  depth  in  Section  3.3. 

1.1.12  Computer  Program  Change  Approval 

The  computer  program  change  approval  is  prepared  by  the 
Program  Change  Control  Board  (PCCB),  indicating  acceptance  by  the 
board  of  the  change  proposal  and  analysis.  It  is  a prerequisite 
to  obtaining  computer  program  change  authorization.  This  is  dis- 
cussed in  depth  in  Section  3.4. 
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1.1.13  Computer  Program  Change 
Authorization 


The  computer  program  change  authorization  (discussed  in  depth 
in  Section  3.^)  is  the  document  which  cites  funding  and  authority 
to  proceed  with  either: 

(a)  An  appropriate  modification  or  change  to  the  existing 
contract  for  the  computer  program. 

(b)  The  preparation  of  a proposed  equipment  engineering 
change  proposal  (ECP). 

(c)  A revision  to  the  operational  specification  and  subse- 
quent contract  action. 

(d)  A combination  of  (a)  and  (b)  or  (b)  and  (c ) . 

1.1.14  Revision  to  Operational  Specification 

The  formal  documentation  of  changes  to  the  Operational 

Specification  is  controlled  by  the  procedures  set  forth  in 
Section  2.2. 

1.1.15  Revision  to  Equipment  Specification 

The  Revision  to  Equipment  Specification  is  the  formal 
documentation  of  a proposed  ECP,  and  is  the  responsibility  of  the 
cognizant  System  Command. 

1.2  Documentation  Library 

The  Documentation  Library  serves  three  specific  functions  in 
the  management  of  a TDS  computer  program.  First,  it  serves  as  the 
repository  for  the  "Authorized  Official  Copy"  of  all  of  the  docu- 
ments in  the  program.  Second,  it  serves  to  control  and  to  record 
the  history  and  evolution  of  each  document.  Third,  it  serves  as  a 
reference  source  available  to  all  personnel  and  activities  involved 
in  the  development,  production  and  operational  use  of  TDS  computer 
programs . 

1.2.1  Rationale  in  Support  of  the 

Documentation  Library  , 

The  most  persistent  problem  which  faces  the  manager  of  a TDS 
computer  program  is  the  control  of  documentation.  A lax  control  or 
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a control  system  not  rigorously  enforced,  can  result  In,  at 
minimum,  the  necessity  for  excessive  debugging  and  extend  to  a 
potential  for  complete  failure  of  the  program  to  meet  its  require- 
ments. At  the  same  time,  a strict  control  system  can  impede  a 
TDS  computer  program,  if  it  is  not  properly  structured  to: 

(a)  permit  ready  access  to  documentation,  by  persons  with  legiti- 
mate reasons  for  access;  and  (b)  provide  a ready  flow  of  docu- 
mentation information.  This  impediment  can  run  the  gamut  from 
annoyance  to  failure  to  meet  significant  milestones  in  the  develop- 
ment, production,  operational  use  and/or  Important  revision  to 
this  program. 

The  Documentation  Library  and  the  control  structure  described 
in  the  remainder  of  this  section  provide  a means  for  achieving  the 
necessary  control  without  impeding  documentation  flow,  while  pro- 
viding ready  access. 


1.2.2  Physical  Requirements  for 
Documentation  Library 

The  Documentation  Library  should  be  established  in  a limited- 
access  space  within  a security  area  appropriate  to  the  security 
classification  of  the  program.  It  should  be  so  constructed  that 
it  can  be  maintained  under  the  control  of  an  assigned  custodian. 
Storage  facilities  should  be  provided  for  8"  x 10-1/2"  manuals. 
Indexed  computer  printout  pages,  EAM  card  decks  and  standard  cor- 
respondence size  files.  Quick-copy  duplicating  facilities  should 
be  provided  and  one  or  more  reading  tables  may  be  provided  to 
delimit  duplicating  load. 

1.2.3  Documents  Included  in  the 
Documentation  Library 

All  of  the  documents  described  in  Section  1.1  of  this  manual 
are  included  in  the  Documentation  Library  under  the  following 
circumstances . 

1.2. 3.1  Two  copies  of  the  TDP  and  SOR  and  two  copies 
of  the  Equipment  Specifications  and  related  documents  (see  1.1.1 
and  1.1.2).  One  copy  of  each  will  be  retained  in  the  Documentation 
Library  at  all  times  for  reference  purposes  within  the  library 
spaces.  The  other  may  be  charged  out  on  loan. 
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1.2. 3.2  Two  copies  of  any  revised  TDP  and  SOR,  and 
Equipment  Specifications  or  related  documents.  One  copy  of  each 
will  be  retained  at  all  times  in  the  library.  If  a superseding 
issue  is  received,  the  loan  copy  will  be  recalled  (and  replaced  by 
the  superseding  issue  if  still  required)  and  destroyed  in  accord- 
ance with  security  regulations.  This  action  will  be  recorded  in 
the  Documentation  Control  List  by  the  custodian.  Both  original 
and  superseding  library  copies  will  be  retained.  If  changes  are 
received  to  these  documents,  the  loan  copy  will  be  recalled,  have 
changes  entered,  and  returned  corrected  if  still  required.  The 
library  copy  will  also  be  changed.  Changes  for  both  copies  will 
be  recorded  in  the  Document  Control  List  (see  Section  1.2.4). 

1.2. 3. 3 One  copy  of  each  draft  document:  (a)  listed 
under  Section  1.1  (except  the  Document  Control  List);  (b)  generated 
within  the  TDS  Computer  Program  Manager's  organizational  control; 
(c)  submitted  for  approval  by  a higher  authority  within  the  TDS 
computer  program  manager's  organization;  and  (d)  assigned  a control 
number;  will  be  provided  to  the  Documentation  Library  certified 
and  dated  by  the  submitter  (see  Section  1.2.5  for  document  identi- 
fication). This  action  will  be  recorded  in  the  Document  Control 
List  by  the  custodian. 

1.2. 3. 4 One  copy  of  each  revision  of  a draft 
document  resulting  from  an  action  under  1.2. 3. 2 (see  Section  1.2.5 
for  document  identification).  This  action  will  be  recorded  in  the 
Document  Control  List  by  the  custodian. 

1.2. 3.5  Two  copies  of  each  approved  document: 

(a)  listed  under  Section  1.1  (except  Document  Control  List);  (b) 
generated  within  the  TDS  Computer  Program  Manager's  organization; 
and  (c)  assigned  a control  number;  will  be  provided  to  the  Docu- 
mentation Library  certified  and  dated  by  the  approving  official 
(see  Section  1.2.5  for  document  identification).  This  action  will 
be  recorded  in  the  Document  Control  List  by  the  custodian.  Oie 
copy  will  be  retained  in  the  library  at  all  times. 
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1.2. 3. 6 Two  copies  of  each  document:  (a)  listed 
under  Section  1.1;  (b)  submitted  to  the  program  manager’s  organi- 
zation for  review,  approval,  or  recommending  a program  change  by  a 
contractor;  (c ) assigned  a control  number  (see  Section  1.2.5  for 
document  Identification)  will  be  provided  to  the  Docimientatlon 
Library,  certified  and  dated  by  the  contractor's  official  sub- 
mitting the  document.  This  action  will  be  recorded  In  the  Docu- 
ment Control  List  by  the  custodian.  One  copy  will  be  retained  In 
the  library  at  all  times.  The  other  may  be  charged  out  on  loan. 

1.2. 3. 7 Two  copies  of  each  document:  (a)  listed 
\inder  Section  1.1;  (b)  submitted  by  a contractor  and  approved  by 
an  authorized  official  of  the  program  manager's  organization;  and 
(c ) assigned  a control  number  (see  Section  1.2  for  document  Iden- 
tification) will  be  provided  to  the  Documentation  Library,  certi- 
fied and  dated  by  the  approving  official.  The  loan  copy  of  the 
document  under  1.2. 3.6  which  Is  superseded  by  this  action  will  be 
recalled  and  destroyed  (replaced  by  the  superseding  document  if 
required)  in  accordance  with  security  regulations.  One  copy  of  the 
approved  document  will  be  retained  in  the  Documentation  Library  at 
all  times.  The  other  copy  may  be  charged  out  on  loan.  The  fore- 
going actions  will  be  recorded  In  the  Document  Control  List  by  the 
custodian. 
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1.2. 3. 8  The  original  and  one  copy  of  each  document 
Included  under  Section  1.2.3  will  be  provided,  upon  receipt,  to  the 
Documentation  Library.  The  custodian  will  assign  a control  number 
in  accordance  with  Section  1.2.5.  The  original  will  be  retained 
(except  as  noted  below)  in  the  Documentation  Library  at  all  times. 
The  other  copy  will  be  marked  "Action  Copy",  annotated  with  the 
assigned  control  niimber  and  transmitted  by  the  custodian  to  the 
appropriate  action  official  In  the  program  manager's  organization. 
Should  It  be  necessary  to  transmit  the  original  to  any  activity 
outside  of  the  program  manager's  organization,  a copy  annotated 
with  the  control  number  and  marked  "Authorized  Official  Copy"  will 
be  placed  In  the  Documentation  Library  and  retained.  The  fore- 
going actions  will  be  recorded  In  the  Document  Control  List  by  the 
custodian. 
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1.2.4  Document  Control  List  (DCL) 

The  Document  Control  List  (DCL)  is  the  responsibility  of  the 
custodian  of  the  Documentation  Library.  Every  document  transaction 
cited  in  Section  1.2.3  will  be  recorded  in  the  DCL.  The  minimum 
requirement  for  an  adequate  DCL  is  a separate  card  for  each  basic 
document  control  number  (columns  1-7  and  9-l4  inclusive,  see  Sec- 
tion 1.2.5)  on  which  is  recorded  the  complete  history  of  the  trans- 
action of  that  document.  The  last  entry  will  indicate  the  current 
status  of  the  docioment.  The  fomnat  of  the  card  provides  for  ready 
conversion  of  data  to  keypunched  EAM  cards  should  the  DCL  be  mecha- 
nized. Mechanization  of  the  DCL  is  particularly  desirable  for  ease 
of  preparing  a periodic  status  summary.  In  this  event,  a separate 
EAM  card  is  prepared  for  each  transaction.  Figure  2 shows  the 
format  for  the  DCL.  It  should  be  noted  that  while  the  document 
title  appears  on  the  DCL  format,  no  provision  is  made  in  the 
columnar  entries  for  other  than  the  document  number  (which  identi- 
fies the  document  for  status  report  printouts  in  the  mechanized 
version  of  the  DCL). 

1.2.5  Document  Control  Numbers 

1.2. 5.1  The  entire  system  documentation  numbering 
system  is  provided  as  a means  for  relating  all  system  documentation. 

The  TDS  Computer  Program  Manager  will  be  concerned  principally  with 
numbers  which  indicate  "9"  in  column  #5.  Column  numbers  refer  to 
those  shown  in  the  DCL  format. 

1.2. 5. 1.1  Coliiiim  #1-4  System  Identifiers 
(SOR/TDP  numbersT 

1.2. 5. 1.2  Column  ^ 

1 - Key  Characteristics 

2 - Technical  Plan 

3 - Management  Plan 

4 - Resources  Plan 

5 - Schedule  Plan  r 

6 - Procurement  Plan  ! 

7 - Logistics  Support  Plan 
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8 - Hardware  Documents 

9 - Software  Documents 


1.2. 5. 1.3  Column  #6 
If  Column  #5  is  1, 

0 - Total  system 

1-9  - Major  subsystem  identifiers 

If  Column  #5  is  2, 

0 - Item  Characteristics 

1 - Associated  Item  Characteristics 

2 - PWBS  Plan 

3 - Reliability  Plan 

4 - Maintainability  Plan 

5 - Technical  Manpower  Plan 

6 - Evaluation  and  Test  Plan 

7 - Technical  Performance  Measurement  Plan 

8 - Com  Sec  Plan 

9 - Supporting  Technology  Plan 

If  Column  #5  is  3, 

0 - Management  Plan 

1 - Management  Organization 

2 - Management  Systems 

3 - Configuration  Management  Plan 

4 - Contract  Definition  Plan 

If  Column  #5  is  4, 

0 - Resources  Plan 

1 - Financial  Plan 

2 - CIR 

3 - Facilities 

4 - Personnel 

6 - Financial  Status  Report 

7 - CIR  Status  Report 

8 - Facilities  Status  Report 

9 - Personnel  Status  Report 
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If  Column  #5  is 

0 - Schedule  Plan 

1 - Milestone  Charts 

2 - PERT  Diagrams 
6 - Status  Reports 

If  Column  #5  is  6, 

0 - Procurement  Plan 

1 - Source  Selection  Plan 

2 - Contract  Plan 

3 - Contractor  Performance  Evaluation  Plan 

6 - Source  Selection  Reports 

7 - Contract  Administration  Reports 

8 - CPE  Reports 

If  Column  #5  is  7, 

0 - Logistics  Support  Plan 

1 - Maintenance  & Supply  Plan 

2 - Personnel  and  Training  Plan 

3 - Technical  Documentation  Plan 

4 - Performance  Measurement  Criteria 

6 - Maintenance  & Supply  Reports 

7 - Personnel  and  Training  Reports 

8 - Technical  Documentation  Reports 

9 - Performance  Measurement  Reports 

If  Column  #5  is  8 or  9, 

0 - Total  system  documents 

1-9  - Major  subsystem  identifier 


1.2. 5. 1.4 
If  Column  #5  is  1-7, 


0 - Total  system 

1-9  - Major  subsystem  identifiers 


If  Column  #5  is  8, 


0 - Total  system  document 

1-9  - Item  Identifiers 
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If  Column  #5  is  9j 


0 - Total  system  manual 

1 - Design  Manual  (Tech  Manual) 

2 - Command  & Staff  Manual 

3 - Operations  Manual 

4 - Training  Manual 

5 - Maintenance  Manual 

6 - Specifications 

7 - Equipment  Description 

8 - Test  & Evaluation  Documents 

9 - Operational  Software  (Program  Tapes,  EAM  card  decks, 

etc . ) 

1.2. 5. 1.5  Column  #6 
If  Column  #5  is  1-7 

0 - Plan  for 

1 - Regular  report 

2 - Special  report 

3 - Informal  report 

4 - Interim  document 

5 - Published  document 

6 - Number  assignment  only.  Document  not  in  Documenta- 

tion Library 

7 - Change  recommendation 

8 - Change  proposal 

9 - Change  approval 

If  Column  #5  is  8, 

0 - Total  system  document 

1-9  - Item  Identifier 

If  Column  ^ is  9> 

0 - Plan 

1 - Regular  report 

2 - Special  report 

3 - Informal  report 

4 - Interim  document 

5 - Published  document 


"If 


6 - Number  assignment  only.  Document  no  In  Documenta- 

tion Library 

7 - Change  recommendation 

8 - Change  proposal 

9 - Change  approval 

1.2. 5. 1.6  Columns  9 and  10 

If  Column  #5  Is  1-7  there  Is  no  entry.  If  Column  #5  Is  8, 
there  Is  no  entry  If  document  is  not  limited  to  a particular 
chassis  or  module;  If  document  is  limited  to  a particular  chassis 
or  module  enter  first  two  digits  of  chassis  or  module  identifier. 

If  Column  #5  is  9>  there  is  no  entry  if  document  is  not  limited  to 
a particular  program  routine;  enter  major  program  routine  identifier 

1.2. 5. 1.7  Columns  11  and  12 

If  Column  #5  is  l-7j  there  is  no  entry.  If  Column  #5  is  8, 
there  is  no  entry  if  document  is  not  limited  to  a particular 
chassis  or  module;  if  document  is  limited  to  a particular  chassis 
or  module,  enter  last  two  digits  of  chassis  or  module  identifier. 

If  Column  #5  is  9>  there  is  no  entry  if  document  is  not  limited  to 
a particular  program  subroutine;  enter  program  subroutine  identifier 

1.2. 5. 1.8  Column  #13 

If  Column  #5  is  1-7,  use  0.  If  Column  #5  is  8, 

0 - If  no  other  number  applies 

1 - Outline  and  mounting 

2 - Wiring  diagram 

3 - Parts  Lists 

4 - Schematic  diagram 

5 - Circuit  description 

6 - Lubricants  & disassembly 

7 - Specifications  and  test  drawings 

8 - Failure  Summary 

9 - Modification 

If  Column  #5  is  9, 

0 - If  no  other  number  applies 

1 - Operational  Specification 
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2 - Program  Flow  Diagram 

3 - Functional  Description  of  Logic  Flow 

4 - Functional  Flow  Chart 

5 - Program  Routines 

6 - Test  Routines 

7 - Program  Listing 

8 - Assembly  Listing 

9 - Simulation  Program 

1.2. 5. 1.9  Column  #l4 

If  Column  #5  is  1-7,  use  0.  If  Column  ^ is  8 or  9, 

0 - If  no  configuration  limitations 

1 - First  configuration 

2 - Second  non-interchangeable  configuration 

3 - Third  non-interchangeable  configuration 

4 - Etc. 

1.2.5.1.10  Column  #15 

If  Column  #5  is  1-7  use  0.  If  Column  #5  is  8 or  9, 

0 - If  no  configuration  limitations 

1 - First  Interchangeable  configuration 

2 - Second  Interchangeable  configuration 

3 - Third  Interchangeable  configuration 

4 - Etc. 

1.2.5.1.11  Columns  #16  and  17  - A - ZZ 

The  letter  "A"  is  assigned  to  the  first  issue  of  a document. 
The  first  change  issued  will  be  lettered  B.  Subsequent  changes 
will  be  letter  C-ZZ. 

1.2.5.1.12  Columns  #l8  and  19  - A - ZZ 

The  letter  "A"  is  assigned  to  the  first  issue  of  a document. 
This  letter  will  appear  on  all  changes  to  the  document  until  a 
revised  document  is  Issued.  When  a revised  document  is  issued,  the 
letter (s)  in  Columns  l8  and  19  will  be  changed  to  the  letter  desig- 
nation of  the  last  change  Incorporated  into  the  revised  docviment. 
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1.2.6  Configuration  Control  Data 
Columns  20-40  of  the  DCL  are  used  for  the  purposes  of 
configuration  control  In  the  following  manner. 

1.2. 6.1  Column  20  will  Indicate  the  organization  of 
the  Initiator  of  the  transaction  to  be  recorded  In  the  DCL. 

0 - Office  of  the  Chief  of  Naval  Operations 

1 - Commandant  of  the  Marine  Corps 

2 - Cognizant  System  Command 

3 - System  Project  Office 

4 - TDS  Computer  Program  Manager 

5 - Computer  Program  Contractor 

6 - Atlantic  Fleet 

7 - Pacific  Fleet 

8 - Alternate  Fleet  Computer  Programming  Center 

9 - Laboratory  or  other  Shore  Activity 

1.2. 6. 2 Columns  21-23  will  Indicate  the  first  three 
digits  or  letterg  of  the  Initiator’s  organizational  codes,  except 
when  Colvimn  20  is  6,  7,  or  9* 

If  Column  20  Is  6 or  J , enter  the  task  group  number  of  the 
Initiator’s  fleet  unit. 

If  Column  20  Is  9,  enter  the  appropriate  laboratory  or  shore 
activity  designator  from  the  following: 

ADC  NADC  Johnsvllle 

AFI  NAFI 

APJ  APL  Johns  Hopkins 

APW  ADL  U of  Washington 

ASL  Applied  Slcence  Lab 

FTC  FAWTTC 

GTC  NAS  Glynco 

MDL  Mine  Defense  Lab 

MEL  Marine  Engineering  Lab 

NCA  NAVCOSSACT 

NEL  Navy  Electronics  Lab 

NMC  Naval  Missile  Center 
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NWL  NWL  Dahlgren 

OCA  OPCONCEN  LANT 

OCH  OPCONCEN,  Hawaii 

OCN  OPCONCEN,  North  Island 

OLC  NOL  Corona 

OLW  NOL  White  Oaks 

RDL  NRDL 

TMB  David  Taylor  Model  Basin 
TSC  NOTS  China  Lake 

TSP  NOTS  Pasadena 

USL  Underwater  Sovind  Lab 

Additional  designators  may  be  added  to  the  above  as  needs  arise. 

Such  additional  designators  will  be  assigned  and  promulgated  by 
the  Documentation  Library  Custodian. 

1.2. 6. 3 Columns  24-27  will  Indicate  the  identification 
of  the  official  authorizing  the  transaction.  The  coding  system  to 
be  used  in  these  columns  will  be  the  dame  as  that  indicated  for 
Columns  20-23  in  Section  1.2. 6. 2. 

1.2. 6. 4 Columns  28-30  will  contain  the  initials  of 
the  custodian  entering  the  transaction  (use  "n"  for  middle  initial 
if  the  custodian  has  none). 

1.2. 6. 5 Columns  31-36  will  indicate  the  date  of  the 

transaction. 


1.2. 6. 6  Columns  37-39  will  indicate  the  milestone 
niomber  Identification  if  it  is  a milestone  document.  If  it  is  not 
a milestone  or  PERT  controlled  document,  these  columns  will  be  left 
blank.  Milestone  numbers  will  be  those  Indicated  in  Section  2.1  of 
this  manual  using  zeros  preceding  the  single  digit  basic  milestone 
number}  e.g..  Milestone  5-1,  Draft  of  Program  Flow  Diagram,  will 
be  entered  as  051  in  columns  37-39«  The  exception  to  this  is  in 
the  area  of  PERT  controlled  documents.  Each  document  under  PERT 
control  will  be  assigned  a number  between  200  and  999«  This  PERT 
ntunber  will  be  entered  in  Columns  37-39* 
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• « 

1.2. 6. 7 Column  40.  When  a milestone  or  a PERT 
- - controlled  docximent  has  been  completed,  an  asterisk  will  be  entered 

in  Column  4o  of  the  transaction  entry  in  the  DCL. 

• * When  a milestone  or  a PERT  date  has  been  passed,  without 

receipt  of  the  Indicated  document,  the  custodian  will  enter  the 
. . letter  "X"  in  column  40.  (Note:  Milestone  or  PERT  dates  are 

entered  manually  in  the  heading  space  provided  on  the  DCL  form. ) 

• . When  a milestone  or  a PERT  date  is  revised  after  having  been 

passed,  the  DLC  shall  substitute  the  letter  "R"  for  the  "X"  in 
column  40. 

• « 

When  a revised  date  is  passed  without  receipt  of  the  indicated 
document,  the  DLC  shall  replace  the  letter  "R"  with  the  letter  "x". 

When  a transaction,  whether  under  PERT  control  or  not,  records 
the  cancellation  or  termination  of  a document  the  letter  "t"  will 
be  Inserted  by  the  DLC. 

■ . When  a transaction,  whether  under  PERT  or  milestone  control  or 

not,  records  the  \maccept ability  of  a doc\iment  which  is  to  be  resub- 
mitted, the  letter  "U"  will  be  inserted  by  the  DLC. 

1.3  Equipment  Description  and  Specification 

The  Equipment  Description  is  prepared  in  the  TDS  program 
management  office,  and  summarizes  the  capabilities  and  critical 
characteristics  of  the  tactical  data  processing  equipment  for  which 
the  TDS  computer  program  is  to  be  prepared.  It  is  based  on  infor- 
mation contained  in  the  Equipment  Specifications  and  equipment 
operating  and/or  technical  manuals.  It  will  completely  describe 
the  input  and  output  characteristics  for  each  piece  of  equipment 
together  with  the  functions  which  the  equipment  is  designed  to  per- 
form. In  essence,  it  is  a translation  of  the  Equipment  Specifica- 
tions from  the  electromechanical  language  of  the  latter  to  the 
functional  language  better  understood  by  computer  program  designers. 

1.3.1  Critical  Characteristics 

! Critical  characteristics  are  the  operational  parameters  of  the 

equipments  in  the  TDS  computer  complex.  These  Include  word  lengths, 
I bit  rates,  storage  capacities,  error  rates,  switching  logic  and 
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other  attributes  of  the  equipment  which  place  a limit  on  the 
functional  capabilities  of  the  component.  While  these  data  are 
normally  available  from  the  component  specifications,  it  is  often 
necessary  to  refer  to  operating  manuals  or  other  documentation  to 
ensure  that  the  critical  characteristics  shown  in  the  Equipment 
Description  exactly  match  those  of  the  equipment  as  they  are  pro- 
duced and  delivered. 

1.3.2  Use  of  Equipment  Description 

The  Equipment  Description  serves  two  purposes.  It  provides 
the  equipment  baseline  for  the  Operational  Specifications  of  the 
TDS  computer  program.  It  also  provides  the  equipment  baseline  for 
the  functional  description  of  logic  flow.  In  serving  the  latter 
purpose,  it  is  included  as  a part  of  the  Procurement  Specification 
for  the  TDS  computer  program.  For  this  reason,  it  is  imperative 
that  close  liaison  be  established  and  maintained  with  the  equip- 
ment designers  and  producers  to  ensure  that  the  Equipment  Descrip- 
tion accurately  portrays  the  capabilities  and  functional 
characteristics  of  each  equipment  in  the  TDS  computer  complex.  This 
liaison  must  be  continued  throughout  the  life  of  the  complex  to 
ensure  that  equipment  changes  are  not  made  which  might  jeopardize 
the  successful  use  of  the  program.  If  equipment  changes  are  made, 
appropriate  Equipment  Description  changes  must  serve  as  a basis  for 
computer  program  changes  to  assure  compatibility  with  the  changed 
equipment  or  to  more  effectively  utilize  the  capabilities  of  the 
changed  equipment.  In  referring  to  Figure  1,  it  will  be  noted 
that  engineering  change  proposals  (ECP's)  lie  outside  the  control  of 
the  TDS  Computer  Program  Manager  and  may  therefore  originate  from 
these  outside  sources.  This  makes  it  imperative  that  personnel 
charged  with  the  responsibility  for  the  Equipment  Description  take 
the  Initiative  in  ensuring  that  all  ECP's  are  reflected  in  the 
Equipment  Description. 

1.3.3  Control  of  the  Equipment  Description 

The  Equipment  Description  is  a critical  document,  basic  to  the 
successful  completion  of  the  TDS  computer  program.  As  such,  its 
control  is  a matter  of  considerable  import  to  the  TDS  Computer 
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Program  Manager.  In  addition  to  being  subject  to  the  controls 
indicated  under  Section  1.2,  the  Documentation  Library  copy  shall 
be  maintained  in  manual  form  such  that  the  current  version  and  all 
previous  Iterations  of  the  document  are  available  for  review.  To 
accomplish  this,  all  corrections,  additions  or  deletions  will  be 
annotated  with  the  revision  and/or  change  number  by  which  these 
were  effected.  When  such  changes,  additions  or  corrections  are 
made  by  replacement  pages,  the  superseded  page  will  be  annotated 
in  the  upper  right  hand  corner  with  the  last  transaction  identifi- 
cation under  which  it  was  effective. 

The  replacement  page  will  be  identified  in  the  upper  right 
hand  corner  by  the  transaction  number  which  made  the  page  effective. 
If  subsequently  superseded,  a line  shall  be  drawn  through  the 
transaction  identification  which  made  the  page  effective  (without 
rendering  the  number  unreadable)  and  the  page  annotated  with  the 
last  transaction  Identification  under  which  it  was  effective.  In 
some  cases,  the  transaction  niunber  which  made  the  page  effective 
and  the  last  transaction  identification  under  which  the  page  is 
effective  may  be  the  same.  In  this  case  only,  the  lining  out  of 
the  former  may  be  omitted.  Both  the  superseded  and  superseding 
page  will  be  retained  in  the  document,  with  the  superseding  page 
Immediately  preceding  the  superseded  page  in  the  sequence  of  pages. 
Under  no  circumstances  will  the  library  copy  be  removed  from  the 
immediate  control  of  the  Documentation  Library  Custodian.  When 
information  is  required  by  personnel  in  other  spaces,  copies  will 
be  provided  by  the  DLC. 

1.4  Operational  Specifications 

The  Operational  Specifications,  together  with  the  Equipment 
Description  discussed  in  Section  1.3>  provides  the  design  envelope 
for  the  TDS  computer  program.  As  well  as  establishing  the  design 
envelopes,  these  two  documents  together  describe  the  objectives  and 
goals  to  be  met  by  the  TDS  computer  program. 


1-25 


1.4.1  Preparation  of  the  Operational 
Specifications 

Operational  Specifications  are  prepared  In  accordance  with  the 
"TDS  Computer  Program  Operational  Specifications  Preparation  Guide" 

by  the  TDS  Computer  Program  Manager's  staff  In 

response  to  the  system  Technical  Development  Plan  (TDP)  and  Its 
enclosed  Specific  Operational  Requirement  (SOR). 

1.4.2  Approval  of  the  Operational 
Specification 

The  Operational  Specification  must  have  the  approval  of  the 
Chief  of  Naval  Operations  or  his  authorized  agent  prior  to  Issuance 
and  Inclusion  In  a Procurement  Specification.  It  Is  recognized 
that  this  approval  requirement  may  Introduce  a time  delay  In  the 
Issuance  of  the  Operational  Specification.  However,  this  delay  Is 
significantly  less  than  the  potential  overall  delay  obtaining  from 
changes  Introduced  at  a later  time  In  the  TDS  computer  program 
development . 

1.4.3  Revisions  and  Changes  to 

the  Operational  Specification 

The  procedures  leading  to  revisions  and  changes  to  the 
Operational  Specification,  after  delivery  of  the  TDS  computer  pro- 
gram, are  discussed  In  Section  3 of  this  manual.  Procedures  for 
changes  and  revisions  prior  to  acceptance  and  delivery  of  the  TDS 
computer  program  are  discussed  below. 

1.4. 3. 1 Changes 

Changes  are  those  modifications,  corrections,  additions,  or 
deletions  to  the  Operational  Specification  which  do  not  effect  the 
scope  of  the  TDS  computer  program  contract  and  which  do  not  result 
In  any  significant  modification  of  the  mission  or  objectives  of  the 
system  supported  by  the  TDS  computer  program  or  significant  modifi- 
cation of  the  TDS  computer  program  Itself. 

1.4. 3.2  Revisions 

Revisions  are  those  modifications,  corrections,  additions  or 
deletions  which  result  from  significant  modification  to  either  the 
mission  or  objectives  of  the  system  supported  by  the  TDS  computer 
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program  or  the  TDS  computer  program  itself.  Depending  upon  the 
status  of  the  contract  and  manner  in  which  the  contract  work  state- 
ment was  written,  revisions  may  or  may  not  effect  the  scope  of  the 
TDS  computer  program  contract. 

1-4. 3. 3 Revisions  and  Changes  Prior  to 

Issuance  of  Request  for  (Rotation  (RFQ) 

Revisions  and  changes  are  initiated  by  staff  personnel  of  the 
TDS  Computer  Program  Manager's  organization.  Revisions  and  changes 
must  be  recorded  on  the  DCL  in  accordance  with  Section  1.2  of  this 
manual.  Changes  during  this  period  may  be  approved  by  the  individ- 
ual responsible  for  the  preparation  of  the  Operational  Specifica- 
tions. Revisions  must  be  approved  by  the  TDS  Computer  Program 
Manager.  Further,  the  revision  which  is  to  be  included  in  the  Pro- 
curement Specification  must  be  concurred  with  and  approved  as  indi- 
cated in  Section  1.4.2.  This  revision  also  must  Include  all 
acceptable  changes  of  record  on  the  DCL  as  of  the  date  of  the  Pro- 
curement Specification. 

1.4. 3.4  Revisions  and  Changes  During  the  Period 
from  Issuance  of  RFQ,  to  Contract  Award 

Revisions  and  changes  during  this  period  should  be  ONLY  those 
considered  absolutely  mandatory  in  obtaining  an  effective  computer 
program  design  due  to  modifications  of  mission  or  objectives  of  the 
system  which  the  TDS  computer  program  supports,  or  to  correct  inad- 
vertent errors.  All  such  changes  or  revisions  must  be  approved  by 
the  TDS  Computer  Program  Manager  prior  to  recording  in  the  DCL.  If 
such  changes  or  revisions  occur  prior  to  the  submission  of  proposals 
by  contractors,  an  amended  RFQ  will  be  Issued.  If  such  changes  or 
revisions  occur  after  submission  of  proposals,  but  before  contract 
award,  their  nature  shall  be  communicated  to  the  Contracting  Officer 
for  a determination  as  to  whether  these  can  be  negotiated  into  the 
contract  by  an  amendment  or  change  order  or  whether  a new  RFQ  and 
bidding  (proposal)  cycle  must  be  undertaken. 

1.4. 3*5  Revisions  and  Changes  During  the  Period 
from  Contract  Award  to  Delivery 

Revisions  and  chamges  during  this  period  should  be  kept  to  a 
minimum,  particularly  after  the  Critical  Design  Review  (see 
Figure  1) . However,  the  TDS  computer  program  must  be  responsive  to 
the  mission  and  objectives  of  the  system  it  supports.  Further,  if 
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the  necessity  for  revisions  arising  as  the  result  of  Fleet  usage 
can  he  anticipated,  they  are  normally  less  expensive  to  achieve 
during  program  preparation  than  after  delivery  of  the  TDS  computer 
program. 

Changes,  as  defined  in  Section  1.4. 3.1,  may  he  authorized  hy 
the  official  responsible  for  preparing  the  Operational  Specifica- 
tions. In  addition  to  the  revision  approval  action  set  forth  in 
Section  1.4. 3. 2,  revisions  should  he  submitted  to  the  Contracting 
Officer  for  determination  of  the  appropriate  contract  action. 

1.4. 3.6  Revision  and  Change  Guidance 

Both  the  TDS  Computer  Program  Manager  and  the  official 
responsible  for  the  preparation  of  the  Operational  Specifications 
are  called  on  to  employ  astute  judgment  in  the  area  of  revisions 
and  changes.  Because  of  the  complexity  of  factors  impinging  on  the 
decision  to  authorize  revisions  or  changes,  a standard  set  of 
decision  rules  are  not  within  the  current  state  of  knowledge. 

In  extreme  cases,  the  Program  Manager  may  submit  the  problem 
to  the  Program  Change  Control  Board  established  under  Section  3.4, 
or,  he  may  use  the  procedures  set  forth  in  Section  3.3.  to  assist 
in  making  a decision  on  revisions  or  changes;  the  latter  is  the 
preferred  course.  However,  it  must  be  borne  in  mind  that  during 
program  development  the  Program  Change  Control  Board  will  not  have 
easy  access  to  the  body  of  data  which  is  available  during  the  pro- 
gram change  management  period  of  contract  performance.  The  proba- 
bility is  that  no  one  apart  from  the  program  manager  and  his  staff 
will  be  better  able  to  evaluate  the  tradeoffs  involved  in  revision 
or  change  decisions. 

1.5  TDS  Computer  Program  Procurement  Specification 

Because  of  the  myriad  considerations  which  must  be  covered, 
the  Procurement  Specification  quite  frequently  is  a source  of  diffi- 
culty to  the  program  manager.  For  this  reason,  a stajidard  Pro- 
curement Specification  has  been  developed.  To  a large  measure,  this 
standard  specification  can  be  used  merely  by  filling  in  the  appro- 
priate blanks.  However,  certain  aspects  of  the  Procurement  Specifi- 
cation, of  which  the  program  manager  must  be  aware,  are  discussed 
in  the  following  subsections. 
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1.5.1  The  Procurement  Specification  as 
a Technical  Document 

Although  not  usually  regarded  as  a technical  document,  the 
Procurement  Specification  does  provide  the  total  technical  envelope 
to  which  the  contractor  can  be  held  legally.  As  such,  it  must 
explicitly  set  forth  all  significant  parameters  which  serve  to 
define  the  technical  effort,  as  well  as  the  technical  limitations 
and  success-failure  criteria  of  the  end  product  of  the  contract. 

Five  documents.  Incorporated  in  the  Procurement  Specification  for 
the  TDS  computer  program  serve  to  insure  compliance  with  these 
requirements.  These  are:  (1)  TDS  Computer  Program  Operational 
Specification  (Section  1.^)  (2)  the  Equipment  Description  (Sec- 
tion 1.3)  (3)  the  TDS  Computer  Programming  Specification 

(4)  the  Specification  for  TDS  Computer  Program  System  Documenta- 
tion  and  (5)  the  Statement  of  Work.  The  first  two  are 

treated  in  the  Indicated  sections  of  this  manual;  (3)  and  (4)  are 
documents  available  to  the  program  manager;  and  (5)  is  a part  of 
the  computer  program  Procurement  Specification  which  is  generated 
by  the  TDS  Computer  Program  Manager's  staff.  It  should  receive  the 
close  personal  attention  of  the  TDS  Computer  Program  Manager.  The 
Statement  of  Work  brings  the  other  referenced  documents  into  con- 
text with  a clear  delineation  of  the  work  to  be  performed  under  the 
contract.  The  smooth  functioning  of  the  work  under  the  contract 
will  be  controlled  in  the  main  by  the  clarity  and  technical  com- 
pleteness of  the  Statement  of  Work.  The  Statement  of  Work  estab- 
lishes the  scope  of  the  contract  effort,  thus  defining  the  technical 
bounds  which  circumscribe  the  contract. 

1.5.2  The  Procurement  Specification  as 
a Business  Document 

As  a business  document,  the  Procurement  Specification  is  a 
joint  responsibility  of  the  TDS  Computer  Program  Manager  and  the 
Contracting  Officer.  The  Joint  concern  cannot  be  overstressed. 
Frequently  there  is  a tendency  on  the  part  of  program  managers  to 
derogate  their  responsibility  to  the  Contracting  Officer.  The  TDS 
Computer  Program  Manager  should  be  in  a better  position  than  the 
Contracting  Officer  to  know  what  the  product  is  that  he  intends  to 
buy  and  what  the  available  resources  are.  These  two  factors  are 
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the  essence  of  the  business  at  hand.  The  Contracting  Officer  can 
provide  the  Inputs  of  how  best  to  arrange  the  business  aspects. 
Nevertheless,  the  overall  success  of  the  transaction  Is  the  pro- 
gram manager's  responsibility. 

As  the  person  of  prime  responsibility,  the  Program  Manager 
should  satisfy  himself  that  the  special  provisions  (often  referred 
to  as  boiler  plate)  are  Indeed  necessary  for  conducting  the  busi- 
ness of  the  contract  which  will  result  from  the  Procurement  Speci- 
fication. If  there  Is  doubt,  he  should  elicit  an  opinion  from  the 
Contracting  Officer. 

1.5.3  The  Procurement  Specification  as 
a Legal  Document 

The  Procurement  Specification  Is  the  legal  document  to  which 
the  contractor  binds  himself  to  perform  under  his  contract.  The 
legal  aspects  of  the  Procurement  Specification,  Including  Its  con- 
formance to  the  requirements  of  the  Armed  Services  Procurement 
Regulations  ajid  statuatory  and  other  regulatory  documents  governing 
the  conduct  of  business  between  private  enterprise  and  the  govern- 
ment, Is  the  principal  responsibility  of  the  Contracting  Officer 
and  his  designated  coiinsel.  Prior  to  the  Issuance  of  the  Procure- 
ment Specification  as  an  attachment  to  a Request  for  Quotation,  the 
Program  Manager  should  ascertain  from  the  Contracting  Officer  that 
the  specification  meets  the  legal  requirements  of  these  regulatory 
documents . 

1.6  Request  for  Quotation 

Section  1.1.7  Indicates  the  forms  which  may  be  used  In 
preparing  a Request  for  Quote.  Specific  guidance  In  preparing  this 
document  Is  contained  In  the  "TDS  Computer  Program  RPQ  Preparation 
Guide".  The  physical  preparation  of  the  document  Is  normally  the 
responsibility  of  the  staff  of  the  Contracting  Officer.  However, 
there  are  a number  of  areas  In  which  the  guidance  of  the  TDS 
Computer  Program  Manager  Is  a vital  Input  to  the  document. 

1.6.1  Method  of  Contracting 

The  method  of  contracting  plays  an  Important  part  In 
determining  the  success  or  failure  of  TDS  computer  program 


1-30 


¥ 


1 


development.  While  the  Contracting  Officer  can  be  expected  to  be 
more  knowledgeable  than  the  Program  Manager  in  the  area  of  advant- 
ages and  disadvantages  of  the  various  contracting  methods,  the  Pro- 
gram Manager  must  have  at  hand  and  provide  to  the  Contracting 
Officer  a complete  explanation  of  the  objectives  of  the  development 
effort,  together  with  a milestone  plan  of  the  development  program 
(see  Section  2.1)  and  an  assessment  of  the  contractors  who  are  con- 
sidered technically  qualified  to  perform  the  work.  These  are 
essential  Inputs  to  a recommendation  by  the  Contracting  Officer  as 
to  the  preferred  method  of  contracting.  In  addition,  should  the 
recommendation  be  to  undertake  a negotiated  contract,  this  infor- 
mation is  imperative  to  permit  the  Contracting  Officer  to  prepare 
a Request  for  Authority  to  Negotiate  (RAN)  and  a Determination  and 
Findings  (D&P),  which  are  prerequisites  to  a negotiated  procure- 
ment. If  this  method  is  recommended,  both  the  RAN  and  D&F  must  be 
approved  at  the  service  secretarial  level  prior  to  Issuance  of 
the  RFQ. 

1.6.2  Proposal  Preparation  Period 

The  period  of  time  allowed  in  the  RFQ  for  contractor  proposal 
preparation  is  in  the  decision  area  of  the  TDS  Computer  Program 
Manager.  This  is  one  of  the  more  critical  elements  in  the  mile- 
stone plan  referred  to  in  Section  1.6.1.  Insufficient  time  will 
result  in  hastily  prepared  proposals  which  tend  to  Increase  the 
risk  of  obtaining  a successful  development.  It  can  also  reduce  the 
competition  among  prospective  contractors  and  nearly  always  results 
in  increased  contract  costs,  since  contractors  recognize  the  risk 
in  a hastily  prepared  proposal  and  will  estimate  costs  accordingly. 
On  the  other  hand,  obvious  delays  in  getting  on  with  the  job 
results  from  an  overly  long  proposal  preparation  period. 

1.6.3  Pre-Proposal  Conference 

If  schedules  can  be  established  to  provide  for  a pre -proposal 
conference,  it  is  advisable.  The  following  advantages  and  dis- 
advantages obtain  from  such  a conference. 
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1.6. 3.1  The  pre-proposal  conference  affords  an 
opportunity  to  insure  that  the  terms  of  the  RPQ  are  xinderstood  by 
all  potential  proposing  contractors.  This  increases  the  probability 
of  receiving  responsive  proposals. 

1.6. 3. 2 The  pre-proposal  conference  affords  an 
opportunity  to  discuss  and  clarify  the  technical  issues  of  the  Pro- 
curement Specification. 

1.6. 3. 3 The  pre-proposal  conference  affords  an 
opportunity  to  expose  specification  defects  which  may  be  perceived 
by  contractor  review  to  the  specifications.  These  frequently  can 
be  cured  by  revisions  to  the  specification  and  amendment  to  the 
RFQ,  without  Jeopardizing  the  contract  award  milestone. 

1.6.3.^  The  principal  disadvantage  to  a pre-proposal 
conference  lies  in  the  work  Involved,  since  very  thorough  prepara- 
tion, organization  and  control  are  necessary  for  the  conference  to 
be  successful.  The  Program  Manager  and  key  personnel  on  his  staff 
as  well  as  the  Contracting  Officer  and  key  personnel  on  his  staff 
must  be  prepared  to  answer  any  and  all  questions  which  may  be  raised 
by  the  participants. 

1.6.4  Prospective  Proposers 

In  a field  as  highly  specialized  as  TDS  computer  programming, 
it  is  imperative  that  the  TDS  Computer  Program  Manager  prepare  a 
thoroughly  evaluated  list  of  prospective  bidders.  Unlike  hardware, 
there  is  no  Qualified  Products  List  for  computer  programs.  Never- 
theless, the  TDS  Computer  Program  Manager  must  develop  such  a list 
as  a guide  to  the  Contracting  Officer  in  the  distribution  of  the 
RFQ.  Although  not  explicitly  required  in  an  advertised  bid,  this 
addressal  of  Invitations  for  bid  insures  that  contractors  considered 
to  be  qualified  to  perform  the  work  are  given  maximum  proposal  prep- 
aration time.  The  TDS  Computer  Program  Manager  must  exercise  dili- 
gence to  Insure  that  all  qualified  contractors  known  to  him  and  his 
staff  are  included  in  the  list  and  that  contractors  known  to  be 
unqualified  are  not  Included.  In  the  latter  case,  he  must  be  pre- 
pared to  defend  his  decision  not  to  include  a contractor  known  to 
him  who  may  claim  subsequently  to  be  qualified. 
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1.6.5  Proposal  Evaluation  Guidance 

The  bases  for  evaluation  of  proposals  must  be  clearly  stated 
In  the  RFQ.  Failure  to  do  so  will  constrain  the  Contracting  Officer 
to  making  an  award  to  the  lowest  bidder.  The  structuring  of  the 
bases  for  evaluation  of  proposals  becomes  extremely  critical.  This 
structuring  is  the  prerogative  of  the  TDS  Computer  Program  Manager 
with  the  advice  of  the  Contracting  Officer  and  his  counsel.  The 
methods  for  such  structuring  are  varied.  The  most  sophisticated  is 
the  structuring  of  an  award  formula  by  which  cost,  schedule,  techni- 
cal and  other  pertinent  factors  are  assessed  and  weighted  to  arrive 
at  an  award  determination.  The  least  sophisticated  method  is  to 
include  a statement  in  the  RFQ  to  the  effect  that  schedule  or  some 
other  factor  will  be  a consideration  of  the  award. 

Perhaps  the  most  significant  factor  in  determining  the  basis 
for  award  is  the  objective  of  the  program.  This  must  be  served. 
Second,  the  structure  must  be  clearly  set  forth  in  as  simple  and 
straightforward  a manner  as  possible.  The  program  manager  must  be 
alert  to  the  pitfalls  of  complex  structures  through  which  he  may  be 
trapped  unwittingly  into  a test  of  gamemanship  with  prospective 
proposers.  This  pitfall  also  exists  in  the  area  of  incentives  which 
is  discussed  in  Section  1.6.6. 

The  test  of  a good  structuring  of  the  bases  for  evaluation  of 
proposals  is  its  defenslbillty.  A homily  to  be  borne  in  mind  is 
that  an  award  decision  makes  only  the  successful  bidder  happy.  All 
the  rest  are  unsuccessful  bidders. 

1.6.6  Incentives 

The  Incentives  to  be  incorporated  into  the  contract  should 
normally  be  explicitly  set  forth  in  the  RFQ.  In  some  cases,  the 
RFQ  may  call  for  proposed  incentives.  In  this  case,  the  proposal 
incentives  become  factors  in  the  evaluation  of  proposals  as  dis- 
cussed in  Section  1.6.5.  The  caution  therein  on  the  gamesmanship 
trap  is  particularly  germane  in  this  case.  The  structuring  of 
incentives  is  in  itself  a proposal  evaluation  weighting  factor  which 
is  subject  to  manipulation;  e.g.,  in  the  inevitable  Juxtaposition 
of  cost  and  schedule,  a prudent  contractor  may  be  expected  to  yield 
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on  the  lesser  weighted  of  the  two,  giving  preference  to  the  more 
heavily  weighted  when  he  determines  that  he  cannot  meet  both.  With 
proper  incentive  structuring,  focused  on  the  objectives  of  the  pro- 
gram, such  a decision  should  be  acceptable  on  a lesser  of  evils 
basis . 

The  incentives,  both  positive  and  negative,  which  may  be 
included  are  too  varied  to  be  treated  in  this  manual.  Guidance  in 
this  area  should  be  elicited  from  the  Contracting  Officer  or  by 
consultation  with  the  Contract  Assistance  Division  of  the  Head- 
quarters, Naval  Material  Command. 


The  proposal  evaluation  team  should  not  be  cited  in  the  RFQ. 
However,  the  TDS  Computer  Program  Manager  should  organize  the  team 
prior  to  the  proposal  closing  date.  This  team  should  be  thoroughly 
familiar  with  the  Procurement  Specification  and  the  RFQ.  The  team 
may  be  organized  as  a technical  evaluation  group  and  a schedule  and 
cost  group,  or,  it  may  be  organized  as  a single  group.  If  the 
latter  organization  is  adopted,  the  team  should  include  the  Con- 
tracting Officer  or  his  representative,  as  well  as  representative 
of  counsel  as  an  ex-officio  member.  The  team  should  be  well 
schooled  in  the  evaluation  method  to  be  used  and  should  be  provided 
with  scoring  sheets  for  the  documentation  of  their  individual 
assessments.  This  latter  provides  the  basis  for  answering  any 
challenge  to  the  award  decision  which  may  subsequently  arise. 


2.  COMPUTER  PROGRAM  DESIGN,  DEVELOPMENT  AND  PRODUCTION 

This  section  of  the  manual  discusses  the  following  activities 
associated  with  computer  program  design,  development  and  production: 

Milestone  Planning  and  Design  Review 
Configuration  Control 
Quality  Control 
Contract  Monitoring 
Design  Testing 
Field  Testing 

There  Is  Interaction  between  many  of  these  activities;  where 
significant  Interaction  Is  evident,  cross-referencing  Is  Included. 
However,  the  TDS  Computer  Program  Manager,  together  with  any  of  his 
I ' staff  having  responsibilities  In  the  areas  of  program  design,  pro- 

; gram  development  or  program  production  should  be  thoroughly  familiar 

with  all  parts  of  this  section. 

2 . 1 Milestone  Planning  and 
Design  Review 

As  Indicated  In  Section  1.6.1,  milestone  planning  begins  well 
before  program  design.  In  Its  grossest  form,  milestone  planning 
for  the  TDS  computer  program  Is  done  In  the  Technical  Development 
Plan  for  the  system  which  the  TDS  computer  program  supports.  The 
TDS  computer  program  milestone  plan  Is  a detailed  expansion  of  the 
TDP  milestone  plan  as  It  pertains  to  the  TDS  computer  program.  Due 
to  Its  critical  role  as  the  key  milestone  In  the  development  of  a 
TDS  computer  program,  design  review  will  be  discussed  In  detail  In 
Section  2.3.1. 

2.1.1  Basic  TDS  Computer 
Program  Milestones 

The  basic  TDS  computer  program  milestones  are  Indicated  In 
Figure  1 by  cross-hatching  Inside  the  symbol.  They  are: 

la.  Equipment  Description  completed 

lb.  Operational  Specification  completed 
2.  Procurement  Specification  approved 
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3.  RPQ  issued 

4.  Contract  awarded 

5.  Program  Plow  Diagram  completed 

6.  Punctional  Description  of  Logic  Plow  completed 

7.  Design  Review  completed  and  Design  Approved 

8.  Punctional  Plow  Chart  completed 

9.  Program  tested 

10.  Program  accepted 

11.  Program  production  started 

12.  Program  deliveries  completed 

2.1.2  Program  Segment  Milestones 

Program  management  planning,  program  design,  production,  and 
Pleet  use  will  each  have  a program  segment  milestone  plan.  Program 
preparation  will  have  two  program  segment  milestone  plans --one  for 
program  preparation  per  se  and  one  for  manual  preparation.  Mile- 
stone planning  for  program  change  management  will  he  discussed  in 
Section  3. 


2.1.2. 1 Program  Management  Planning 
Milestone  Plan 

The  following  minimum  milestones  will  be  included  in  the 
program  management  planning  segment  plan. 

la-1  Receipt  of  Equipment  Specifications  and  Manuals 

la-2  Draft  of  Equipment  Description 

la-3  Internal  review  of  Equipment  Description 

la-4  System  Project  Manager  review  of  Equipment  Description 

la-5  TDS  Computer  Program  Manager's  approval  of  Equipment 
Description 

la-6  Distribution  of  Equipment  Description 

lb-1  Receipt  of  TDP/SOR 

lb-2  Draft  of  Operational  Specification 

lb-3  Internal  Review  of  Operational  Specification 

lb-4  TDS  Computer  Program  Manager,  approval  of  Operational 
Specification 
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lb-5  Concurrence  of  System  Project  Manager 

lb-6  OPNAV  Project  Sponsor  approval  of  Operational 
Specification 

lb-7  Distribution  of  Operational  Specification 

2-1  Receipt  of  Equipment  Description  and  Operational 
Specification 

2-2  Completion  of  basic  TDS  Computer  Program  Milestone  Plan 

2-3  Draft  of  Work  Statement 

2-4  Internal  review  of  work  statement 

2-5  TDS  Computer  Program  Manager  approval  of  work  statement 

2- 6  Assembly  of  Procurement  Specification 

3- 1  Completion  of  Procurement  Specification 

3-2  Determination  of  method  of  contracting 

3-3  Determination  of  proposal  evaluation 

3-4  Determination  of  contract  incentives 

3-5  Draft  of  RFQ 

3-6  Review  of  RFQ  by  Contracting  Officer 

3-7  Review  of  RFQ  by  counsel 

3-8  Preparation  of  RAN  and  D&F  if  required 

3-9  Departmental  approval  of  RAN  and  D&F 

3-10  TDS  Computer  Program  Manager  approval  of  RFQ 

3- 11  Issuance  of  RFQ 

4- 1  Receipt  of  proposal 

4-2  Technical  Evaluation  of  proposals 

4-3  Contract  Evaluation  of  proposals 

4-4  TDS  Computer  Program  Manager  recommendation  of  award 

4-5  Award  of  contract 
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2. 1.2. 2 Program  Design  Milestone  Plan 
The  following  minimum  milestones  will  be  included  in  the 
program  design  segment  plan: 


5-1  Draft  of  Program  Flow  Diagram  completed 

5-2  Contractor/TDS  Computer  Program  Mainager  review  of  Pro- 
gram Flow  Diagram 

5-3  Informal  acceptance  of  Program  Plow  Diagram 


6-1  Draft  of  Functional  Description  of  Logic  Flow  completed 

6-2  Contractor/TDS  Computer  Program  Manager  review  of  Func- 
tional Description  of  Logic  Flow 

6-3  Informal  acceptance  of  Functional  Description  of  Logic 
Flow 


7-1  Conduct  of  formal  critical  design  review  of  the  TDS 
Computer  Program  Design 

7-2  Determination  of  needed  contract  modifications,  if  any 

7-3  Completion  of  contract  modification,  if  needed 

7-4  Delivery  of  contract  modification  to  contractor 

7-5  Complete  negotiation  of  contract  modifications 

7-6  Informal  review  of  Program  Flow  Diagram  revisions 

7-7  Informal  review  of  Functional  Description  of  Logic  Plow 
review 

7-8  Critical  Design  Review  of  revised  TDS  Computer  Program 
design 

7-9  Approval  of  design  by  TDS  Computer  Program  Manager  and 
design  release 

2. 1.2. 3 Program  Preparation  Milestone  Plan 
Program  preparation  segment  milestones  will  be  developed  on 
parallel  tracks.  One  will  be  for  the  preparation,  testing  and 
acceptance  of  the  program  Itself  including  its  reference  documents. 
This  will  Include  mlnimiam  milestones  set  forth  in  Section  2. 1.2. 3.1. 
The  other  will  be  for  the  preparation  of  field-use  documents  and 


2-4 


j 

i 

} 


FT 


will  Include  milestones  as  set  forth  in  Section  2. 1.2. 3. 2.  Because 
of  the  high  degree  of  interrelation  between  the  two  sets  of  mile- 
stones, a PERT  chart  should  be  developed  for  the  program  prepara- 
tion segment  setting  forth  the  two  critical  paths  and  their 
interrelationships . 

2. 1.2. 3.1  Preparation  of  the  Program 

8-1  Draft  of  Functional  Flow  Chart  completed 

8-2  Contractor/TDS  Computer  Program  Manager  review  of  Func- 
tional Flow  Chart 

8-3  Informal  acceptance  of  Ihinctional  Flow  Chart 

8-4  Contractor's  submission  of  program  preparation  PERT 
chart  including  program,  reference  and  field-use 
documents 

8- 5  TDS  Computer  Program  Manager  acceptance  of  program 

preparation  PERT  Chart 

9- 1  Begin  program  testing 

9-2  Complete  Test  Routine  Testing 

9-3  Start  Simulation  Testing 

9-4  Complete  Simulation  Testing 
9-5  Start  Field  Testing 

9-6  Complete  Field  Testing 

9- 7  Accept  program 

10- 1  TDS  Computer  Program  Manager  acceptance  of  program  and 

reference  documents. 

2. 1.2. 3. 2 Preparation  of  Field-Use 
Documents 

8-6  Draft  System  Programmer's  Reference  Manual  submitted 

10-2  System  Programmer's  Reference  Manual  accepted  by  TDS 
Computer  Program 
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8-7  Draft  of  System  Plan  Manual  completed 

10-3  System  Plan  Manual  accepted  by  TDS  Computer  Program 
Manager 

8-8  Draft  of  System  Program  Design  Manual  completed 

10-4  System  Program  Design  Manual  accepted  by  TDS  Computer 
Program  Manager 

8-9  Draft  of  System  Operation  Manual  completed 

10-5  System  Operation  Manual  accepted  by  TDS  Computer  Pro- 
gram Manager 

8-10  Draft  of  System  Program  Maintenance  Manual  completed 

10-6  System  Program  Maintenance  Manual  accepted  by  TDS  Com- 
puter Program  Manager 

8-11  Draft  of  Command  and  Staff  Manual  completed 

10-7  Command  and  Staff  Manual  accepted  by  TDS  Computer  Pro- 
gram Manager 

8-12  System  Program  Assembly  Listing  completed 

10- 8  System  Program  Assembly  Listing  accepted  by  TDS  Com- 

puter Program  Manager 

8-13  Reference  Master  Program  Tape  delivered  to  TDS  Computer 
Program  Manager 

2. 1.2, 4 Production  Milestone  Plan 

11- 1  Release  for  production 

11- 2  Complete  delivery  instructions  for  field-use  documents 

and  program  tapes 

12- 1  Complete  deliveries 
2.2  Configuration  Control 

Configuration  control  is  defined  herein  as  the  measures 
established  by  the  TDS  Computer  Program  Manager  to  insure  that  all 
documentation  is  precisely  controlled  in  a manner  which  provides 
for  a continuous  status  surveillance  of  the  TDS  computer  program. 
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The  term  "configuration  control"  Is  used  in  a broader  context 
with  regard  to  hardware  systems.  In  a TDS  computer  program,  docu- 
mentation--whether  manuals,  EAM  cards,  computer  printouts  or  tapes-- 
constitutes  the  entire  end  product  of  the  effort.  Therefore, 
configuration  control  and  documentation  control  become  synonymous. 

2.2.1  Configuration  Control  Standards 

The  configuration  control  standards  include  the  "Specification 
for  TDS  Computer  Program  Systems  Documentation"  as  the  principal 
standard,  the  "TDS  Computer  Programming  Specification, " the  Equip- 
ment Description  and  the  Operational  Specifications.  These  stand- 
ards also  serve  in  the  area  of  quality  control  which  will  be 
discussed  in  Section  2.3.  Quality  control  procedures  together  with 
the  design  review  comprise  the  mechanisms  for  effecting  qualitative 
configuration  control. 

2.2.2  Configuration  Control  Center 

The  core  of  the  configuration  control  mechanism  is  the 
Documentation  Library  (see  Section  1.2).  In  addition  to  its  func- 
tion as  the  official  repository  for  documents,  the  Documentation 
Library  includes  the  Document  Control  List  (DCL),  which  is  the 
vehicle  for  exercising  configuration  control. 

2.2.3  Configuration  Control  Procedures 

All  documents,  whether  generated  within  the  TDS  Computer 
Program  Manager's  staff  or  by  the  contractor's  organization,  which 
pertain  to  a TDS  computer  program  will  be  assigned  a document  con- 
trol number  in  accordance  with  Section  1.2.5  of  this  manual.  The 
first  eight  numbers  will  be  assigned  by  the  Documentation  Library 
Custodian  (DLC).  These  may  be  obtained  from  the  DLC  by  telephone 
or  other  means.  When  he  makes  this  assignment,  he  will  make  a DCL 
entry  indicating  the  initiator's  identification.  The  initiator 
should  at  the  same  time  supply  the  information  required  to  complete 
columns  9-19  of  the  DCL.  The  DCL  will  confirm  the  availability 
(no  duplication)  of  the  identifiers  in  columns  9-19  of  the  DCL. 

This  completes  the  document  Identification.  In  addition,  the 


2-7 


initiator  will  indicate  to  the  DLC  the  identification  of  the 
milestone  or  PERT  control  number  applicable  to  the  document  for 
entry  in  columns  37-39  of  the  DCL. 

The  initial  version  of  each  document  will  be  identified  as 
"Change  A,  Revision  A"  (Columns  I7  and  19  in  the  DCL).  Prior  to 
initiating  any  subsequent  change  or  revision  to  a document,  the 
initiator  will  contact  the  DCL  for  assignment  of  a change  and/or 
revision  letter  designation. 

Copies  of  each  document  will  be  provided  to  the  DCL  as 
indicated  in  Section  1.2.3  of  this  manual. 

2.2.4  Configuration  Control  Status  Report 

2.2.4. 1 When  the  DCL  is  mechanized,  a weekly  summary 
report  will  be  prepared  by  the  DLC.  This  report  will  be  a printout 
of  the  last  transaction  entry  on  each  DCL  item.  From  this,  the  TDS 
computer  program  manager  will  be  able  to  determine: 

(a)  The  latest  change  issued 

(b)  The  latest  revision  Issued 

(c)  The  Initiator 

(d)  Document  classification,  and 

(e)  Date. 

of  all  documents  under  the  program.  In  addition,  the  report  will 
reflect  progress  status  of  the  documentation  on  an  exception  basis; 
i.e.,  it  will  indicate  milestones  or  PERT  dates  met,  missed,  or 
revised.  In  the  case  of  milestone  or  PERT  dates  not  yet  reached, 
the  TDS  Computer  Program  Manager  can  compare  the  program  status 
report  with  milestone  or  PERT  dates  to  determine  which  docviments 
appear  to  be  potential  problems . The  program  status  report  will 
further  indicate  to  him  the  Initiator  of  the  last  DCL  transaction 
who  should  be  the  best  source  of  detailed  status  information. 

2. 2. 4. 2 When  the  DCL  is  not  mechanized,  a monthly 
summary  report  will  be  prepared  by  the  DLC. 
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2.2.4. 3 The  distribution  of  the  configuration  control 
status  reports  should  be  limited  to  key  management  personnel. 
Determination  of  distribution  is  the  prerogative  of  the  TDS  Com- 
puter Program  Manager.  Specific  status  inquiries  should  be 
directed  to  the  DLC.  Such  inquiries  may  be  made  by  telephone,  since 
current  status  on  any  item  is  indicated  by  the  latest  DCL  entry. 

2.2.5  Configuration  Control  Enforcement 

The  configuration  control  process  described  in  Section  2.2  of 
this  manual  is  designed  to  provide  positive  control  of  all  docu- 
mentation. However,  unless  the  TDS  Computer  Program  Manager  insists 
that  all  personnel  involved  in  the  program  observe  the  requirements 
of  the  process  it  will  not  meet  its  intended  purpose.  Enforcement 
can  be  achieved  through  two  mechanisms.  The  first  is  to  take  no 
cognizance  of  any  document  which  does  not  bear  a valid  documentation 
number.  The  second  is  to  use  the  DCL  as  the  only  recognized  source 
of  status  information  (see  Section  2.4).  These  two  mechanisms  will 
force  all  participants  to  insure  the  recording  of  all  document 
transactions  in  the  DCL.  Until  participants  become  accustomed  to 
working  with  the  system,  the  TDS  Computer  Program  Manager  can 
expect  resistance  to  the  "red  tape."  Nevertheless,  if  there  is  to 
be  control,  all  participants  must  be  made  to  be  responsive  to  the 
control  process.  The  alternative  is  to  relinquish  control,  thereby 
jeopardizing  the  timely  meeting  of  objectives  and  almost  certainly 
increasing  overall  program  costs. 

2 . 3 Quality  Control 

Quality  control  in  a TDS  computer  program  is  achieved  in  four 
separate  functional  areas.  The  most  significant  of  these  is  the 
critical  design  review.  The  second  area  is  essentially  an  inspec- 
tion type  of  action  to  determine  compliance  with  specifications. 

The  third  area  is  the  proofing  or  design  testing  of  the  program 
itself  through  the  use  of  test  routines  and  the  simulation  program. 
The  fourth  and  final  quality  control  area  is  field  testing. 

2.3.1  Critical  Design  Review 

The  critical  design  review  is  conducted  by  the  TDS  Computer 
Program  Manager  in  concert  with  the  contractor.  It  involves  a 


searching  review  of  the  program  flow  diagram  and  the  functional 
description  of  logic  flow  in  terms  of  the  Operational  Specification, 
the  Equipment  Description  and  the  "TDS  Computer  Programming  Speci- 
fication." It  is  axiomatic  that  the  quality  of  the  developed  pro- 
gram is  circumscribed  by  the  adequacy  and  validity  of  the  critical 
design  review.  This,  in  turn,  is  a function  of  the  qualifications 
of  the  design  review  team  and  the  thoroughness  with  which  the  review 
is  conducted.  For  this  reason,  in  establishing  the  design  review 
team  the  TDS  Computer  Program  Manager  should  not  be  reluctant  to 
augment  his  staff  with  consultants.  In  terms  of  quality  control 
^lnder  the  contract,  the  critical  design  review  offers  more  payoff 
than  any  other  single  activity  in  the  development  of  a TDS  computer 
program. 

Adequate  time  must  be  allocated  for  this  function.  However,  if 
the  design  review  is  not  methodically  planned  and  executed,  addi- 
tional time  will  avail  little.  In  this  regard,  the  critical  design 
review  should  be  conducted  by  the  team  in  relative  isolation,  with 
essentially  no  time  lapses  between  review  sessions. 

2.3.2  Specification  Compliance 

Each  document,  which  is  to  be  a delivered  item  under  the 
contract,  should  be  submitted  in  draft  form  by  the  contractor. 

Each  should  be  reviewed  by  the  cognizant  member  of  the  TDS  Computer 
Program  Manager's  staff  or  a quallfj**'  ..d  authorized  agent  thereof, 
to  determine  its  compliance  with  the  "Computer  Program  Procurement 
Specifications."  This  determination  is  Intended  to  apply  to  the 
qualitative  content  of  the  document.  It  should  not  concern  itself 
with  the  physical  aspects  of  the  document  such  as  weight  and  type 
of  paper,  typography,  etc.  These  latter  should  be  matters  of  final 
acceptance  of  the  product  rather  than  quality  control  of  the  program. 

2.3.3  Testing 

The  two  types  of  testing  which  contribute  to  quality  control, 
design  testing  and  field  testing,  are  discussed  in  Sections  2.5  and 
2.6,  respectively.  In  relation  to  quality  control,  the  TDS  Computer 
Program  Manager  should  assure  himself  that  the  design  and  field 
tests  are  structured  in  a manner  to  guarantee  their  value  as  quality 
assessment  tools. 
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2.4  Contract  Monitoring 

Quality  control  as  an  aspect  of  contract  monitoring  is 
discussed  in  Section  2.3  and  will  not  be  treated  in  this  section. 

By  the  same  token,  testing  Is  an  aspect  of  contract  monitoring. 

This  is  discussed  in  Section  2.5  and  2.6.  The  remaining  part, 
management  and  progress  monitoring  is  discussed  in  this  section. 

2.4.1  Basis  for  Monitoring 

Management  and  progress  monitoring  is  based  on  two  techniques, 
the  milestone  plan  for  the  program  and  the  PERT  plan  for  the  develop- 
ment of  the  computer  program.  The  milestone  plan  is  discussed  in 
Section  2.1,  as  is  the  requirement  for  a PERT  control  plan.  The 
milestone  plan  is  the  responsibility  of  the  TDS  Computer  Program 
Manager.  The  PERT  control  plan  is  the  responsibility  of  the  con- 
tractor. Once  the  contractor's  PERT  control  plan  has  been  accepted 
by  the  TDS  Computer  Program  Manager,  any  revisions  thereto  are  sub- 
ject to  the  latter's  acceptance  and  approval.  PERT  revisions  which 
result  in  revisions  to  milestones  are  subject  to  contract  modifica- 
tion with  appropriate  compensations  as  a function  of  responsibility 
for  the  revision.  The  TDS  Computer  Program  Manager  should  advise 
the  Contracting  Officer  when  this  occurs. 

2.4.2  Contract  Monitoring  Procedure 

The  contract  monitoring  procedure  is  premised  on  the  use  of 
the  DCL  as  the  monitoring  vehicle  (see  Section  1.2.6).  Each  mile- 
stone has  an  associated  document  which  is  subject  to  documentation 
control  and  is  identified  on  the  DCL  by  its  milestone  number. 

Each  PERT  item  has  an  associated  document  which  is  subject  to  docu- 
mentation control  and  is  identified  on  the  DCL  by  its  PERT  number 
(see  1.2. 6. 7).  As  a result,  the  weekly  summary  status  report  in  the 
mechanized  DCL  or  the  monthly  summary  status  report  in  the  manual 
DCL  serves  to  provide  management  and  progress  data  to  the  TDS  Com- 
puter Program  Manager.  He  can  monitor  through  one  or  more  of  the 
following : 

(a)  Check  the  summary  status  report  (Column  4o)  for  (com- 
pleted items),  X (overdue  items),  U(\insatisfactory  items), 
and  T(terminated  items). 
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(b)  Review  all  milestone  and  PERT  items  coming  due  in  the  week 
following  the  siimmary  status  report  to  determine  latest 
transaction  (Columns  I6-19)  and  document  classification 
(Column  8). 

(c)  Check  with  Initiator  (Columns  20-23)  to  obtain  more 
detailed  status  Information  if  required. 

(d)  Request  special  printouts  by  Column  4o  entries. 

2.4.3  Rationale  Underlying  Contract 
Monitoring  Procedure 

In  a software  program  such  as  a TDS  computer  program 
development,  all  progress  is  represented  by  a document.  In  order 
to  maintain  control  over  this  documentation,  it  must  be  recorded. 

The  foregoing  procedures  use  the  recording  mechanism  as  the  moni- 
toring vehicle  rather  than  to  require  the  preparation  of  additional 
reports.  This  procedure  serves  a second  purpose  in  that  it  requires 
all  participating  personnel,  both  government  and  contractor,  to 
record  their  documentation,  and  thereby  bring  it  under  control, 
before  any  progress  credit  obtains.  This  further  frees  the  program 
manager's  staff  to  concentrate  on  quality  control  within  the  con- 
tractor's facility,  rather  than  expend  time  on  status  monitoring. 

2.5  Design  Testing 

Design  testing,  or  debugging  as  it  is  more  commonly  called,  is 
the  first  part  of  program  testing  (Milestone  9).  It  consists  of  two 
separate  exercises  of  the  program  in  the  computer  and  peripheral 
equipment  for  which  it  is  designed.  The  peripheral  equipment  does 
not  Include  the  equipment  which  generates  raw  input  data  to  the 
computer  complex,  e.g.,  radar  or  target  acquisition  equipment;  nor 
does  it  Include  output-use  equipment  such  as  fire  control  or  data 
link  transmission  equipment.  The  first  exercise  employs  the  Test 
Routines  and  the  second  the  Simulation  Program.  Normally,  both 
exercises  are  done  in  a government  facility  using  government  fur- 
nished equipment  and  witnessed  by  a member (s)  of  the  TDS  Computer 
Program  Manager's  staff. 
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2.5.1  Test  Routine  Testing 

The  computer  program  will  be  exercised  In  the  computer  complex 
driven  by  the  Test  Routines.  This  will  continue  until  a program 
failure  Is  detected.  The  exercise  will  then  be  halted,  necessary 
corrective  action  taken  and  the  changes  or  revisions  recorded  In  the 
DCL.  This  may  be  done  by  telephone  to  the  DLC,  but  must  be  followed 
by  a document  submission,  since  the  DLC  will  record  a telephone 
transaction  with  the  number  "6"  In  column  8 of  the  DCL  to  Indicate 
that  no  document  has  been  received.  When  the  corrective  action  Is 
completed,  the  computer  program  will  be  re-exercised  from  "start" 
until  another  program  failure  is  detected.  The  procedure  described 
for  the  first  detected  program  failure  will  be  repeated  and  the 
exercise  will  be  continued  until  the  computer  program  has  been 
exercised  for  three  consecutive  full  cycles  of  the  Test  Routine 
without  encoTonterlng  a program  fault.  The  TDS  Computer  Program 
Manager  should  ensure  that  Test  Routine (s)  to  test  the  adequacy  of 
"inhibit  illegal  action"  design  provisions  are  included. 

The  TDS  Computer  Program  Manager  will  ensure  that  this  test  is 
included  as  a part  of  the  success -failure  criteria  in  the  state- 
ment of  work  of  the  Procurement  Specification  as  well  as  in  its  test 
requirements  section. 

2.5.2  Simulation  Program  Test 
f Proofing  Test) 

The  computer  program  will  be  exercised  in  the  computer  complex 
using  the  Simulation  Program  as  Inputs  to  the  test.  The  Simulation 
Program  will  be  designed  to  demonstrate  the  ability  of  the  TDS 
computer  to  meet  the  Operational  Specifications  included  in  the 
Procurement  Specification.  Three  consecutive  full  cycles  without  a 
program  failure  of  the  Simulation  Program  are  required  to  meet  this 
part  of  program  testing.  Failing  this,  the  contractor  will  be 
required  to  take  the  necessary  corrective  action.  The  changes  or 
revisions  generated  by  this  corrective  action  must  be  recorded  in 
the  DCL.  As  with  corrective  actions  under  Test  Routine  testing, 
this  may  be  done  by  telephone  to  the  DLC,  but  must  be  followed  by 
a document  submission. 


In  the  event  that  changes  or  revisions  are  made  to  the  TDS 
computer  program  during  the  Simulation  Program  test,  the  contractor 
will  be  required  to  re-exercise  the  program  with  the  Test  Routine. 

If  the  program  completes  without  program  failure  a full  cycle  of  the 
Test  Routine  the  first  time  through,  no  further  Test  Routine  test- 
ing will  be  required  for  the  changes  or  revisions  tested.  However, 
falling  this,  both  Test  Routine  testing  and  Simulation  Program 
testing  must  be  repeated  until  success  is  achieved  with  both  tests. 
The  TDS  Computer  Program  Manager  will  ensure  that  this  test  is 
Included  in  the  success-failure  criteria  in  the  statement  of  work 
of  the  Procurement  Specification,  as  well  as  in  its  test  require- 
ments section. 

2.6  Field  Testing 

Field  testing  is  the  exercise  of  the  computer  program  in  the 
computer  and  peripheral  equipment  including  data  input  generating 
equipment  and  output-use  equipment.  This  test  must  be  completed  in 
an  operational  environment.  A necessary  part  of  this  operational 
environment  is  the  use  of  military  personnel  as  operators  who 
possess  the  skill  level  required  by  the  Operational  Specifications. 
The  TDS  Computer  Program  Manager  should  ensure  that  the  field  test 
plan  stays  within  the  bounds  prescribed  by  the  Operational 
Specification. 

2.6.1  Responsibility  for  Conducting 
Field  Tests 

Field  tests  pertaining  to  the  contract  are  normally  conducted 
by  the  Test  and  Evaluation  Section  of  a Fleet  Computer  Programming 
Center.  It  is  the  responsibility  of  the  TDS  Computer  Program  Mana- 
ger to  provide  the  FCPC  T&E  Section  with  the  technical  test  plan. 
This  test  plan  will  reflect  the  constraints  Imposed  by  the  Opera- 
tional Specifications  even  though  these  constraints  may  be  opera- 
tional in  nature  rather  than  technical. 

Should  the  FCPC  T&E  Section  elect  to  conduct  field  tests 
outside  the  bounds  of  the  Operational  Specification,  the  TDS  Com- 
puter Program  Manager  should  advise  them  that  acceptance  of  the 
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work  under  the  contract  must  he  premised  only  on  that  part  of  the 
field  testing  which  lies  within  the  bounds  of  the  Operational 
Specification. 


I 

1 
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2.6.2  Observation  of  Field  Testing 

The  TDS  Computer  Program  Manager  himself  or  his  deputy  should 

observe  the  field  testing.  Normally  contractors'  representatives 
also  serve  as  observers. 

2.6.3  Field  Testing  Success -Failure 
Criteria 

The  TDS  Computer  Program  will  be  exercised  in  each  of  the 
modes  of  operational  employment  prescribed  by  the  Operational  Spe- 
cification. If  successful  operation  is  achieved  within  the  tol- 
erances prescribed  in  the  Operational  Specification  on  the  first 
field  test  In  that  mode,  the  program  will  be  adjudged  as  having 
passed  In  that  mode. 

If  the  program  falls  on  the  first  field  test  in  any  given  mode 
of  operation  It  shall  be  adjudged  as  having  not  passed.  If  indi- 
cations are  that  failure  was  due  to  equipment  malfiinction,  either 
computer  complex,  input  or  output-use,  corrective  action  will  be  j 

taken  and  the  field  test  repeated.  If  in  the  second  test  success-  | 

ful  operation  Is  achieved  within  the  tolerances  prescribed  in  the  i 

Operational  Specification,  the  program  will  be  adjudged  as  having  I 

passed  In  that  mode.  If  Indications  are  that  failure  was  due  to 
the  malfunctioning  of  the  computer  program,  necessary  corrective 
action  will  be  taken  and  changes  or  revisions  recorded  in  the  DCL. 

This  may  be  done  by  telephone  or  naval  message  to  the  DLC,  but  I 

must  be  followed  by  a document  submission.  The  program  will  then  | 

be  exercised  In  the  field  equipment  by  use  of  the  Test  Routine  | 

fo\ind  in  the  "System  Program  Maintenance  Manual".  The  Test  Routine  ] 

must  be  successfully  completed  prior  to  re-conductlng  the  field 
test.  A program  having  failed  in  an  operating  mode  due  to  program 
failure  must  subsequently  achieve  successful  operation  within  the  I 

tolerances  prescribed  In  the  Operational  Specification  in  two  con-  | 

j 

secutlve  field  tests  in  that  mode  before  it  can  be  adjudged  as  } 

t 

having  passed  the  field  test  in  that  mode.  | 


The  TDS  Computer  Program  Manager  should  ensure  that  the 
statement  of  work  of  the  Procurement  Specification  clearly  indi- 
cates the  field  testing  aspects  of  the  success-failure  criteria, 
as  well  as  including  it  in  the  test  section. 

2.6.4  Acceptance  Under  the  Contract 
A TDS  computer  program  having  met  the  foregoing  and  the  tests 
indicated  in  Section  2.5  will  he  considered  as  having  been  accepted 
under  the  contract.  This  may  not  indicate  necessarily  acceptance 
for  service  use.  If  not,  it  may  be  necessary  to  modify  the  contract 
through  a change  in  Operational  Specifications.  Section  3 discusses 
the  procedures  to  be  used  in  this  eventuality. 


3.  PROGRAM  CHANGE  MANAGEMENT 

This  section  of  the  manual  provides  procedures  for  the  orderly 
control  of  changes  to  the  TDS  Computer  Program.  A program  change, 
as  differentiated  from  a document  change  defined  in  Section  1.4. 3.1, 
is  a redevelopment  of  one  or  more  program  routines  or  subroutines 
occasioned  by  a revision  to  the  Operational  Specification  and/or 
the  Equipment  Description.  A program  change  usually  results  in  a 
contract  change  order,  a contract  amendment  or  the  Issuance  of  a 
new  contract  to  effect  the  change. 

Program  changes  stem  from  one  or  more  of  the  following 
situations : 

(a)  A change  in  the  Intended  operational  employment  (mission) 
of  the  system  which  the  TDS  Computer  Program  supports. 

(b)  A change  in  the  configuration  of  the  equipment  in  the 

computer  complex.  | 

(c)  An  advance  in  equipment  technology  or  programming 
methodology. 

(d)  A revision  of  tactics  based  on  operational  forces' 
experience  with  the  program. 

(e)  Revisions  in  performance  characteristics  of  own  or 
friendly  vehicles  and/or  sensors  Inputting  to  the  com- 
puter complex,  to  be  processed  within  the  computer  com- 
plex and/or  being  controlled  or  directed  by  the  outputs 
of  the  computer  complex. 

(f)  Revisions  in  estimated  or  predicted  performance  character- 
istics of  •unfriendly  or  enemy  vehicles  and/or  sensors  to 
be  processed  within  the  computer  complex. 

3.1  Change  Recommendations 

Three  categories  of  change  recommendations  are  Contractor 
Change  Recommendations,  Fleet  (Operating  Forces)  Change  Recommenda- 
tions, and  Fleet  Computer  Programming  Center  Cheuige  Recommendations. 
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The  latter  Includes  all  program  change  recommendations  stemming 
from  a,  b,  e,  and  f,  as  Vfell  as  those  initiated  by  departmental 
levels  under  c,  above. 

3.1.1  Format  of  Program  Change 
Recommendations 

Program  change  recommendations  will  be  prepared  using  the 
following  format : 

From: 

To : 

Subject:  TDS  Computer  Program  Change  Recommendation 
Document  N\jmber * 

1.  Purpose  of  change 

2.  Recommended  change  to  Operational  Specification 

3.  Recommended  change  to  Equipment  Description 

U.  Impact  of  change  on  the  TDS  computer  program 

5.  Discussion  of  advantage  and  disadvantages  of 
change 

6.  Recommendations  as  to  timing  of  change 

7.  Discussion  of  alternatives  to  the  change 
recommendation 

* Fleet  Change  Recommendations  will  provide  a blank  for 
the  document  number  which  will  be  assigned  by  the  DLC, 
who  in  turn  will  advise  the  originator  of  the  number 
assigned.  FCPC's  and  contractors  will  obtain  a docu- 
ment number  from  the  DLC  before  preparing  the  change 
rec  ommendat ion . 

3.1.2  Processing  the  Program  Change 
Recommendations 

After  signature,  all  program  change  recommendations  will  be 
directed  to  the  Docvimentation  Library  for  recording  and  distribu- 
tion. After  review  and  comment  by  appropriate  members  of  his  staff, 
the  TDP  Computer  Program  Manager  will  determine  whether  the  change 
recommendation  will  be  processed  into  a specific  program  change 
proposal,  held  for  incorporation  with  other  change  recommendations 
into  a program  change  proposal,  or  not  accepted.  In  the  latter 
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decision,  the  originator  will  be  advised  of  the  decision  by  letter. 
This  will  be  entered  as  a transaction  by  the  DLC  with  the  letter 
"T"  being  Inserted  in  Column  40  of  the  DCL. 

3.2  Change  Proposals 

Program  change  proposals  are  the  documentation  of  one  or  more 
change  recommendations  which  have  been  accepted  by  the  TDS  Com- 
puter Program  Manager  for  analysis  and  consideration  for  submission 
to  the  Program  Change  Control  Board  (PCCB).  Program  change  pro- 
posals are  prepared  by  the  TDS  Computer  Program  Manager's  staff. 

3.2.1  Format  of  the  Program  Change  Proposal 

The  program  change  proposal  is  a package  consisting  of: 

(a)  A cover  sheet  bearing  the  document  identification  number 
assigned  by  the  DLC  and  a description  of  the  change. 

(b)  The  change  recommendation (s ) Included  in  the  program 
change  proposal. 

(c)  A list  of  the  documents  to  be  affected. 

(d)  An  estimate  of  dollar  costs  and  time  required  to  effect 
the  change . 

(e)  A milestone  and/or  anticipated  PERT  chart  to  manage  the 
accomplishment  of  the  change. 

(f)  A statement  of  the  contract  modifications  (or  new  con- 
tract) requirements  needed  to  effect  the  change. 

3.2.2  Processing  the  Program 
Change  Proposal 

Upon  completion  of  the  program  change  proposal,  it  will  be 
submitted  to  the  TDS  Computer  Program  Manager,  via  the  DLC  for 
recording,  for  determination  of  disposition.  The  TDS  Computer  Pro- 
gram Manager  may  elect  to  accept  the  proposal  and  conduct  a program 
change  analysis,  hold  the  proposal  in  abeyance,  or  not  accept  the 
proposal.  In  the  latter  case,  the  proposal  will  be  returned  via 
the  DLC  (for  entry  of  the  letter  "T"  in  Column  4o  of  the  DCL)  to 
the  proposal  originator,  ainnotated  as  not  accepted. 
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3*3  Program  Change  Analysis 

Program  change  analysis  uses  as  its  Inputs  the  program  change 
proposal  and  the  documentation  of  the  program  available  from  the 
Documentation  Library.  The  purpose  of  the  analysis  is  to  make  a 
thorough  and  detailed  examination  of  the  change  proposal  and  Its 
ramifications.  These  shall  include  considerations  in  the  follow- 
ing areas ; 

(a)  Impact  of  the  change  proposal  on  the  mission  of  the  sys- 
tem supported  by  the  TDS  computer  program  by  modes  of 
operation. 

(b)  Specific  penalties,  in  terms  of  operations,  which  obtain 
if  the  change  proposal  is  not  accepted. 

(c)  Specific  penalties,  in  terms  of  operations,  which  are 
imposed  by  the  change  proposal. 

(d)  Feasibility  of  accomplishing  the  change  proposal. 

(e)  Analysis,  in  terms  of  a - d above,  of  alternatives  cited 
in  the  change  recommendation (s ) . 

(f)  Study  to  determine  if  other  alternatives  are  available. 

(g)  Analysis,  in  terms  of  a - d above,  of  any  other  developed 
alternatives . 

3.3.1  Purpose  of  Program  Change 
Analysis 

Fundamentally,  the  program  change  analysis  is  intended  to 
provide  visibility  to  all  factors  which  may  enter  into  a decision 
by  the  PCCB  to  approve  or  disapprove  a program  change  proposal. 

The  program  change  analysis  report,  together  with  the  program 
change  proposal,  constitutes  the  package  which  is  presented  to  the 
PCCB  for  decision.  The  combination  of  the  two  should  stand  alone 
without  the  need  for  other  supporting  material. 

3.3.2  Program  Change  Coordination 
Center  fPCCCl 

The  TDS  Computer  Program  Manager  will  have  access  to  either 
the  PCCC  PAC  or  PCCC  LANT.  The  PCCC's  consist  of  knowledgeable 
personnel  from  the  two  Fleet  Computer  Programming  Centers  (FCPC's) 
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who  are  chartered  with  the  responsibility  for  providing  prograjmning 
expertise  to  the  FCPC's.  The  PCCC  assigned  the  responsibility  for 
the  specific  program,  conducts  the  program  change  analysis. 


3.3*3  Preparation  and  Format  of  the 
Program  Change  Analysis 

Since  there  are  numerous  possible  combinations  of  factors, 
depending  upon  the  nature  of  the  program  change  proposal,  no  spe- 
cific format  for  the  program  change  analysis  is  considered  to  be 
warranted.  The  Program  Change  Coordination  Center  (PCCC)  conducting 
the  analysis  should  structure  the  approach  to  and  determine  the 
method (s)  to  be  followed  in  conducting  the  analysis.  This  will 
include  milestones  (PERT,  if  necessary)  in  achieving  the  analysis 
itself. 

3.3.^  Program  Change  Analysis  Report 

Upon  completion  of  the  change  analysis,  a report  shall  be 
prepared.  This  will  include  the  following: 

(a)  The  analysis  approach. 

(b)  The  analytic  findings. 

(c)  The  conclusions  reached  in  the  analysis. 

(d)  The  recommendations  of  the  analysis  team. 

This  report,  when  approved  by  the  TDS  Computer  Program  Manager, 
will  be  attached  to  the  program  change  proposal  and  forwarded  to 
the  PCCB.  Since  the  PCCB  normally  does  not  meet  in  formal  session, 
it  is  imperative  that  the  program  change  analysis  report  be 
thorough  and  complete  in  all  respects. 

3.4  Program  Change  Approval  and 
Authorization 

Program  change  approval  is  the  function  of  the  Program  Change 
Control  Board  (PCCB).  Program  change  authorization  is  a subsequent 
action  taken  by  the  TDS  Computer  Program  Manager.  This  latter 
action  includes  the  funding  and  obtaining  of  authorization  to  take 
any  necessary  contract  action  to  implement  the  program  change. 
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3.4.1  Program  Change  Control 
Board  (PCCB) 

The  Program  Change  Control  Board  (PCCB)  is  composed  of 
representatives  of  the  concerned  commands  in  the  Navy  as  set  forth 
in  OPNAVINST  03500.27. 

3.4.2  Procedures  for  Program 
Change  Approval 

The  TDS  Computer  Program  Manager,  upon  receipt  of  the  program 
change  proposal  and  its  attached  program  change  analysis,  wixl 
review  the  two  documents  and  take  one  of  the  following  actions : 

(a)  Hold  the  proposal  in  abeyance. 

(b)  Return  the  proposal  to  the  PCCC  for  further  analysis. 

(c)  Disapprove  the  proposal,  notifying  the  PCCC  and  origi- 
nator (s)  of  the  change  recommendation (s ) via  the  DLC  for 
recording,  of  his  decision. 

(d)  Prepare  a forwarding  letter  to  the  chairman  of  the  PCCB, 
with  copies  to  appropriate  members,  to  transmit  the  pro- 
gram change  proposal  and  its  analysis  for  action  by  the 
PCCB.  The  forwarding  letter  should  include  milestone 
dates  for; 

1.  Recommendation  for  a formal  meeting  of  the  PCCB  to 
consider  the  proposal,  if  deemed  necessary, 

2.  Return  of  recommended  approval  action  to  the  chairman, 

3.  PCCB  action  notification  to  the  TDS  Computer  Program 
Manager. 

3.4.3  Procedures  for  Program 
Change  Authorization 

Exact  standard  procedures  for  program  change  authorization  are 
not  practicable.  In  the  main,  the  TDS  Computer  Program  Manager 
must  exercise  his  own  judgment  as  to  the  best  means  to  proceed. 

For  purposes  of  illustration,  however,  the  most  straightforward  but 
least  frequently  encovintered  situation  is  discussed.  This  situa- 
tion involves  a proposed  change  which  can  be  covered  by  existing 
authorized  funds. 
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Upon  receipt  of  approval  of  the  PCCB,  the  TDS  Computer  Program 
Manager  prepares  a contract  change  order  which  includes  the  revision 
to  the  Operational  Specification  and,  if  involved,  the  revision  to 
the  Equipment  Description.  He  provides  this,  together  with  the 
milestone  (and  a PERT)  information  and  a statement  of  justification 
for  the  contract  change  order,  to  the  Contracting  Office.  The  Con- 
tracting Officer  will  prepare  a RAN  and  D&F  which  he  submits  to 
Headquarters,  Naval  Material  Command  for  approval.  Receipt  of  this 
approval  constitutes  the  last  step  in  the  authorization  of  the  pro- 
gram change.  The  Contracting  Officer  may  now  proceed  with  negoti- 
ation of  the  contract  change  order. 

3.^.^  Post  Change  Authorization 
Procedures 

Reference  should  be  made  to  Figure  1 of  this  manual, 
specifically  to  the  symbol  "Contract  Change  Order".  This  indicates 
the  point  of  entry  into  the  program  cycle  for  post  change  authori- 
zation action.  Subsequent  activities  for  the  contract  change  order 
follow  the  same  flow  as  those  for  the  basic  contract.  The  TDS  Com- 
puter Program  Manager  should  ensure  that  the  contract  change  order 
Includes,  for  the  program  changes,  all  of  the  test  and  other 
requirements  set  forth  for  the  basic  contract. 


3-7 


4. 


SUMMARY 


The  purpose  of  this  section  is  to  set  forth  in  summary  form 
the  contents  of  the  preceding  sections  and  to  discuss  them  in  con- 
text with  some  of  the  more  significant  general  management  problems 
which  will  be  faced  by  the  TDS  Computer  Program  Manager. 

4.1  Operational  Specifications  and 
Equipment  Descriptions 

The  Operational  Specification  and  the  Equipment  Description 
are  by  far  the  two  most  critical  documents  involved  in  the  manage- 
ment of  a TDS  Computer  Program.  As  may  be  expected,  many  problems 
arise  in  connection  with  the  development  of  these  two  documents. 

In  the  case  of  the  Operational  Specification,  the  TDS  Computer 
Program  Manager  can  expect  difficulty  in  obtaining  functional 
requirements,  specific  operational  criteria  and  tolerance  limits  on 
performance  functions.  The  imcertainties  regarding  the  actual 
strategic  and  tactical  problems  which  the  operating  forces  will  face, 
create  a situation  wherein  prudent  military  planners  are  loath  to 
be  really  specific  in  delineating  the  missions  of  major  systems. 

They  are  faced  with  the  dilemma  created  by  the  paradox  between 
flexibility  of  forces  and  limitation  of  force  numbers. 

In  such  a case,  the  TDS  Computer  Program  Manager  can  let  the 
situation  control  him  or  he  can  control  the  situation.  Successful 
management  offers  no  option;  he  must,  in  fact,  elect  the  latter. 

This  is  a difficult  but  not  impossible  task  since  the  approach  to 
solution  of  this  problem  is  somewhat  elementary.  In  laying  out  the 
guidance  for  the  specifics  in  the  development  of  the  Operational 
Specification,  the  gaps  in  received  operational  guidance  become 
quite  apparent.  Using  his  own  backgroimd  and  Judgment  (supplied 
by  the  combined  experience  of  his  staff  members),  the  TDS  Computer 
Program  Manager  determines  what  values  should  be  assigned  to  the 
missing  data.  These  are  then  stipulated  as  assiomptions  under  the 
program.  These  assumptions,  together  with  their  supporting  ration- 
ales, should  be  stated  carefully  and  Included  as  an  appendix  to  the 
Operational  Specification  when  it  is  submitted  for  approval. 


4-1 


r “ 


I 

i 


i- 


[ 

i 

I 

i 

I 


¥ 


The  problems  with  regard  to  Equipment  Descriptions  are  somewhat 
different  and,  in  some  respects,  more  difficult  of  solution.  The 
principal  contribution  to  the  difficulties  lies  in  the  fact  that 
many  things  which  Impact  on  the  Equipment  Description  occur  com- 
pletely outside  of  the  control,  and  sometimes  without  the  knowledge, 
of  the  TDS  Computer  Program  Manager. 

The  solution  to  these  problems  comes  from  a great  deal  of 
diligent  effort.  Constant  liaison  with  the  Project  Manager  of  the 
equipment  and  the  establishment  of  a good  rapport  with  the  equip- 
ment project  staff  are  sine  qua  non.  The  TDS  Computer  Program 
Manager  must  ensu]*e  that  he  is  on  the  distribution  list  for  all 
specifications,  manuals  and  Engineering  Change  Proposals  (ECPs)  for 
the  equipments  which  comprise  the  computer  complex  in  which  the  TDS 
Computer  Program  is  to  be  used. 

4.2  Contracting 

The  TDS  Computer  Program  Manager  must  become  thoroughly 
conversant  with  the  contracting  aspects  of  his  program  and  he  must 
be  aware  of  the  options  which  are  available  to  him.  This  is  best 
done  by  bringing  his  Contracting  Officer  into  the  team  very  early 
in  the  management  planning  part  of  the  development  cycle.  Fre- 
quently, options  in  contracting  method  become  unavailable  because  a 
late  start  precludes  obtaining  necessary  authorizations  within  the 
time  requirements  of  the  program. 

Contrary  to  rather  prevalent  beliefs,  there  is  a great  deal  of 
flexibility  in  government  contracting.  The  notion  that  award  must 
always  be  made  to  the  lowest  bidder  is  completely  fallacious. 

Rather,  the  Armed  Services  Procurement  Regulations  stress  repeatedly 
that  awards  are  to  be  premised  on  the  best  Interests  of  the  govern- 
ment. The  establishment  of  what  constitutes  the  best  Interests  of 
the  government  is  the  responsibility  of  the  TDS  Computer  Program 
Manager.  This  can  be  accomplished  only  if  careful  and  thorough 
management  planning  has  been  done  in  a timely  manner.  Lacking  this, 
the  Contracting  Officer  must  resort  to  the  cost  criterion  as  repre- 
sentative of  the  best  Interest  of  the  government. 


1 


! 


4-2 


4.3  Program  Design 

Even  as  the  Operational  Specification  and  the  Equipment 
Description  are  the  most  critical  documents  in  the  management  of  a 
TDS  Computer  Program  development,  the  critical  program  Design  Review 
is  probably  the  most  important  single  functional  activity  in  the 
management  of  a TDS  computer  program  development.  Once  this  step  is 
passed,  the  design  philosophy  is  frozen  even  though  the  design 
itself  may  not  be  frozen  completely.  Significant  changes  beyond 
this  point  become  exceedingly  expensive  in  terms  of  both  dollars 
and  time.  Therefore,  it  is  incumbent  upon  the  TDS  Computer  Program 
Manager  that  the  review  be  conducted  with  meticulous  care  and  great 
thoroughness . 

4.4  Documentation 

Documentation  is  the  cohesive  factor  which  holds  the  TDS  com- 
puter program  together.  As  such,  its  control  provides  the  essential 
overall  management  of  the  program  development.  The  management 
method  of  this  manual  employs  document  control  through  the  medium 
of  the  Dociimentatlon  Control  List  (DCL)  as  the  principal  management 
tool.  The  TDS  Computer  Program  Manager  should  be  thoroughly  con- 
versant with  the  documentation  control  process.  Further,  he  must 
insist  that  all  participants  assiduously  adhere  to  the  requirements 
of  the  documentation  control  system.  This  must  extend  to  the  con- 
tractor's personnel  as  well  as  to  government  personnel. 

4.5  Change  Management 

Much  of  the  careful  planning  and  the  results  of  good  management 
in  the  development  of  the  TDS  computer  program  can  be  lost  if  strict 
change  management  is  not  enforced.  This  includes  the  types  of 
changes  discussed  in  Section  1.4. 3. 1>  as  well  as  those  discussed  in 
Section  3.  In  the  case  of  the  former,  the  problem  lies  in  the  area 
of  doc\imentation.  The  TDS  Computer  Program  Manager  and  his  staff 
must  be  constantly  alert  to  ensure  that  all  such  changes  are  docu- 
mented. Any  failure  to  document  must  not  be  tolerated.  If  such 
failures  do  occur,  they  must  be  dealt  with  vigorously  to  avoid 
repetition. 
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In  the  type  of  changes  discussed  in  Section  3,  problems  arise 
through  delays  in  receiving  notice  of  PCCB  action.  Onerous  as  the 
task  may  be,  the  TDS  Computer  Program  Manager  must  take  vigorous 
follow-up  action  to  ensure  that  PCCB  decisions  are  received  within 
the  milestone  constraints.  Since  many  of  the  members  of  the  PCCB 
are  not  under  the  direct  control  of  the  TDS  Computer  Program  Mana- 
ger, he  must  call  on  all  of  his  managerial  and  diplomatic  skills  to 
avoid  undue  delays  in  the  program  change  management  part  of  the 
program  cycle.  This  is  particularly  true  when  there  are  inter- 
dependencies among  program  change  proposals  and  when  there  are  sig- 
nificant operational  considerations  attaching  to  a specific  program 
change  proposal. 

4.6  Manual  Revisions 

This  manual  is  and  should  be  a viable  document.  Advances  in 
management  methodology  are  occurring.  In  addition  to  the  somewhat 
obvious  evolutionary  changes  which  will  occur  in  the  coding  system 
in  Section  1.2.5,  it  is  anticipated  that  refinements  and  additions 
to  this  manual  will  be  appropriate  from  time  to  time.  Each  using 
TDS  Computer  Program  Manager  should  contribute  to  the  further 
development  of  this  manual  by  recommending  changes  siiggested  by  his 
experience  in  using  it.  In  this  way,  the  manual  provides  a means 
for  retaining  managerial  learning  and  experience  which  might  other- 
wise be  lost.  These  contributions  should  be  forwarded  to  the 
originator  of  the  manual  together  with  the  rationale  supporting  the 
recommended  changes. 
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